MySQL Galera Cluster 4.0 е новото дете в блока на базата данни с много интересни нови функции. В момента той е достъпен само като част от MariaDB 10.4, но в бъдеще ще работи и с MySQL 5.6, 5.7 и 8.0. В тази публикация в блога бихме искали да разгледаме някои от новите функции, които идват заедно с Galera Cluster 4.0.
Поточно репликация на клъстер на Galera
Най-важната нова функция в тази версия е поточно репликацията. Досега процесът на сертифициране за клъстер Galera работеше по начин, че цели транзакции трябваше да бъдат сертифицирани след приключването им.
Този процес не беше идеален в няколко сценария...
- Горещи точки в таблици, редове, които много често се актуализират на множество възли - стотици бързи транзакции, изпълнявани на множество възли, модифицирането на един и същ набор от редове води до чести блокирания и връщане назад на транзакции
- Дългосрочни транзакции - ако една транзакция отнема значително време за завършване, това сериозно увеличава шансовете някаква друга транзакция междувременно, на друг възел, да промени някои от редовете, които също са били актуализирани от дългата транзакция. Това доведе до блокиране по време на сертифицирането и една от транзакциите трябваше да бъде отменена.
- Големи транзакции - ако дадена транзакция модифицира значителен брой редове, вероятно е друга транзакция, в същото време, на различен възел, да промени един от редовете, които вече са променени от голямата транзакция. Това води до задънена улица по време на сертифицирането и една от транзакциите трябва да бъде върната назад. В допълнение към това големите транзакции ще отнемат допълнително време, за да бъдат обработени, изпратени до всички възли в клъстера и сертифицирани. Това не е идеална ситуация, тъй като добавя забавяне към ангажиментите и забавя целия клъстер.
За щастие, стрийминг репликацията може да реши тези проблеми. Основната разлика е, че сертифицирането се извършва на части, където няма нужда да се чака завършването на цялата транзакция. В резултат на това, дори ако транзакцията е голяма или дълга, по-голямата част (или всички, в зависимост от настройките, които ще обсъдим след малко) от редовете се заключват във всички възли, което не позволява на други заявки да ги променят.
Опции за поточно репликация на клъстер на MySQL Galera
Има две опции за конфигурация за поточно репликация:
wsrep_trx_fragment_size
Това показва колко голям трябва да бъде даден фрагмент (по подразбиране е настроен на 0, което означава, че репликацията на поточно предаване е деактивирана)
wsrep_trx_fragment_unit
Това показва какво всъщност представлява фрагментът. По подразбиране това е байтове, но може да бъде и „инструкции“ или „редове“.
Тези променливи могат (и трябва) да бъдат зададени на ниво сесия, което дава възможност на потребителя да реши коя конкретна заявка трябва да бъде репликирана с помощта на поточно репликация. Задаването на единица на „изявления“ и размер на 1 позволява например да се използва поточно репликация само за една заявка, която например актуализира гореща точка.
Можете да конфигурирате Galera 4.0 да удостоверява всеки ред, който сте променили, и да вземете ключалките на всички възли, докато правите това. Това прави стрийминг репликацията страхотна за решаване на проблеми с чести блокирания, които преди Galera 4.0 беше възможно да се решат само чрез пренасочване на всички записи към един възел.
WSREP таблици
Galera 4.0 въвежда няколко таблици, които ще помогнат за наблюдение на състоянието на клъстера:
- wsrep_cluster
- wsrep_cluster_members
- wsrep_streaming_log
Всички те се намират в схемата „mysql“. wsrep_cluster ще предостави представа за състоянието на клъстера. wsrep_cluster_members ще ви даде информация за възлите, които са част от клъстера. wsrep_streaming_log помага за проследяване на състоянието на поточно репликацията.
Предстоящи функции на клъстера на Galera
Codership, компанията зад Galera, все още не е завършена. Успяхме да получим предварителен преглед на пътната карта от главния изпълнителен директор Сепо Якола, която беше дадена в Percona Live по-рано тази година. Очевидно ще видим функции като поддръжка на XA транзакции и gcache криптиране. Това е наистина добра новина.
Поддръжката за XA транзакции ще бъде възможна благодарение на поточно репликацията. Накратко, XA транзакциите са разпределените транзакции, които могат да се изпълняват в множество възли. Те използват двуфазен комит, който изисква първо да се придобият всички необходими заключвания, за да се изпълни транзакцията на всички възли и след това, след като е направено, да се записват промените. В предишните версии Galera нямаше средства за заключване на ресурси на отдалечени възли, с поточно репликация това се промени.
Gcache е файл, който съхранява набори за запис. Съдържанието му се изпраща до възли за свързване, които изискват трансфер на данни. Ако всички данни се съхраняват в gcache, joiner ще получи само липсващите транзакции в процеса, наречен Incremental State Transfer (IST). Ако gcache не съдържа всички необходими данни, ще се изисква прехвърляне на моментна снимка на състоянието (SST) и целият набор от данни ще трябва да бъде прехвърлен към свързващия възел.
Gcache съдържа информация за последните промени, затова е чудесно да видите съдържанието му криптирано за по-добра сигурност. С въвеждането на по-добри стандарти за сигурност чрез все повече и повече регулации е изключително важно софтуерът да стане по-добър в постигането на съответствие.
Заключение
Определено очакваме с нетърпение да видим как Galera Cluster 4.0 ще работи върху бази данни от MariaDB. Възможността за внедряване на MySQL 5.7 или 8.0 с Galera Cluster ще бъде наистина страхотно. В крайна сметка Galera е едно от най-широко тестваните решения за синхронна репликация, които се предлагат на пазара.
