MySql Cluster

[gbdesign]

Здравейте колеги, някой правил ли е MySql Cluster? При мен пуснах 1 с 2 лоад балансера, 2 Mysql сървъра и мениджмънтският сървър. Инсталирани са на виртуални машини с прилични ресурси. Интересното е че пробен сайт с немалка база, работи няколко в пъти по-бавно, от колкото с един Mysql сървър на една виртуална машина, с аналогични параметри на тези в клъстера. Та се чудя къде е проблема. Знам че материята е отнесена, но някой може и да се е занимавал...

[111111]

Географската репликация активна ли е?

http://cyrenity.word...nners-tutorial/

http://dbperf.wordpress.com/tag/mysql-cluster-geographical-replication/

[gbdesign]

Нямам идея какво имаш в предвид под "географска репликация"...

root@mysql-mgm:~# ndb_mgm

-- NDB Cluster -- Management Client --

ndb_mgm> show

Connected to Management Server at: localhost:1186

Cluster Configuration

---------------------

[ndbd(NDB)]	 2 node(s)

id=10   @172.16.200.23  (mysql-5.5.27 ndb-7.2.8, Nodegroup: 0)

id=20   @172.16.200.24  (mysql-5.5.27 ndb-7.2.8, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)

id=100  @172.16.200.22  (mysql-5.5.27 ndb-7.2.

[mysqld(API)]   4 node(s)

id=1    @172.16.200.11  (mysql-5.5.27 ndb-7.2.

id=2    @172.16.200.12  (mysql-5.5.27 ndb-7.2.

id=3 (not connected, accepting connect from any host)

id=4 (not connected, accepting connect from any host)

ndb_mgm>

[/code]

Това е активно... в същност всичко си работи ок, но е бавноооо...

[hgd]

Здравей,

Преди време правих разни опити с клъстер на MySQL. При мен резултата беше подобен на твоя - много по-ниска скорост.

Разбира се, има причини.

Това, което помогна при мен, но остана само теоретично (заради цената):

- Нужни са ти поне 4 нода

- Нужна ти е много рам за нодовете - 12-16GB и нагоре (с по-малко е зор)

- Нужни са ти бързи връзки между нодовете - 1Gbps е минимума (нужна е агрегация на поне 2-4 порта)

- Нужни са SAS-ове в RAID 10 (SSD го забрави, SATA прегрява).

Моите изводи от тестовете са:

- Ако 32 ядра и 256GB стигат за базата - няма нужда от клъстер.

- Ако имаш над 10 милиона транзакции в час, клъстера е решение, но го смятай в отношение поне 1:4 (реална към клъстер машина).

- По-голяма сигурност и лесно надграждане при клъстера.

За по-висока производителност - Percona, TokuDB (и винаги се подразбира 64bit системи)

И малко идеи:

- тествай с по-ниски времена на TimeBetweenGlobalCheckpoint

P.S. Малко дълго стана, но темата е интересна. А ако помогне на някой - още по-добре.

Редактирано 11 Септември, 2012 от hgd

[111111]

Географската репликация казва на клиент да се обръща към определена база а не към произволна.

Така синхронизацията на базата от входящи заявки и запитване към тях няма да чака синхронизацията.

Или поне такава е идеята.

[gbdesign]

Има само една база за тестовете, така че продължавам да не схващам. Репликация в буквалният смисъл не ползвам. В същност базите си се достъпват от всички MySqld сървъри, а на лод-балансерите се извършва самото синхронно репликиране. Виртуалките са с по 12 Gb RAM и са на общ Софтуерен райд масив, с обикновени SATA III дискове. Всяка от тях е със заделени 2x4 ядра по 2 Ghz. Нямам идея къде може да има тясно място а и нищо не се товари. Всичкото това е на сървър с 2 x 6 ядрени Ксеона. Ползвам KVM виртуализация.

От инсталирана на същият сървър VM със същите параметри, като тези в клъстера, външен Apache сървър си работи съвсем нормално с копие на същата БД.

Редактирано 15 Септември, 2012 от gbdesign

[hgd]

Разгледай този файл, ако не си:

http://www.percona.c...luster_PT_2.pdf

Сега поразгледах за 7.2.x - горещо препоръчват да се направи "ANALYZE TABLE XXX" преди изпълнение на заявките върху съответната таблица. И nbd-cluster-connection-pool трябва да е поне 2 и повече (в my.cnf).

Редактирано 11 Септември, 2012 от hgd

[gbdesign]

Ха.. това ме накефи... Онлайн конфигуратор, генериращ всички конфиг файлове и скриптове...

http://www.severalnines.com/resources/configurator

[amateur]

Остави сървъра да работи 24ч. и пусни този скрипт http://mysqltuner.pl/mysqltuner.pl След което си оптимизираш my.cnf

ААА съжалявам. Ти си намерил решение на проблема

Редактирано 14 Септември, 2012 от amateur

[gbdesign]

Не съм намерил решение... В същност, до колкото се разчетох, клъстеризацията на MySql изначало не е правена за Уеб, а за "по-сериозни цели". Тоест, кратките времена за респонс, хич не са гонени. А на мен ми трябва хем високо натоварване, хем скалируемост, хем сигурност, хем бързодействие, като явно за всичкото това, няма решение на база MySQL...

[hgd]

като явно за всичкото това, няма решение на база MySQL...

Да, така е. Опитай с PostgreSQL и Firebird (по-добре се справя от mySQL при SELECT-и). Oracle и DB2 са доста ресурсоемки (за Informix искат пари ...)

[computer]

доста от големите компании ползват mysql без някакви сериозни промени по него, за изключително много заявки за секунда.

Прегледайте си кода, със сигурност с още една абстракция ще може да постигнете желаното и без клъстер

[gbdesign]

Кода го пишат десетина програмиста и доста ще се узоря, ако тръгна да го преглеждам. Исках да постигна високо ниво на надеждност, щото при гръмване, по каквато и да било причина на MySQL сървър, ще доведе до внимателно, ръчно преглеждане на многобройни транзакции. Държа да ползвам MySql, защото всички потенциални аномалии свързани с него, вече са се случвали и някой е намерил и публикувал решение на проблема. Пък и миграция към друг БД сървър, ще струва прекалено много излишни пари. SQL Cluster ми изглеждаше перфектният вариант и нямах и най-малка идея, че работи толкова мудно. Една седмица загубих в експерименти с конфигурации, настройки, заделяне на ресурси и резултата винаги беше отчайващ. Като се разтърсих за информация по въпроса, се оказа че това си е "нормално" и решение за ускоряване дефакто няма. Отделно има някакви безумни лимити, като размера на заявката, липса на поддръжка на Foreign keys и т.н.

Та в крайна сметка ще си ползвам обикновени MySQL сървъри, с репликации за бекъпи и ISCSI или DRDB външни сториджи и виртуализация за НА.

[computer]

ами попринцип ако сега се прави приложението не е нужно да го преглеждаш, a да се обсъди с програмистите, все пак и те са хора :-)

Ако проекта ще е голям може да разгледаш някое от платените приложения за mysql, там със сигурност ще откриеш каквото търсиш поне като идея

За лимитите не съм съгласен, всички могат да се променят включително размера на заявката и разбира се че има Foreign keys, но не и в myisam

В зависимост какъв тип са данните и как се достъпват се мислят различни тактики, като цяло е трудно да се направи универсална конфигурация валидна за всички случаи, та в този ред на мисли Mysql cluster-а е по подходящ за нещо по общо, отколкото за конкретен проект, където може с голяма точност да профилираш всичко

[gbdesign]

Foreign keys, няма в актуалната версия 7.2.8 а ще има в 7.3, когато излезе. Таблици с MyISAM и InoDB енджин, не влизат в клъстера а си седят само на MySQLd сървъра, на който са създадени. Клъстера работи само с таблици с NDBCLUSTER енджин. Миграция към примерно Postgre, ще струва, по груба сметка, към 200 К лв., без да броим пропуснатите ползи от забавяне на проекта... тоест, не е оферта...