В един от предишните блогове разгледахме нови функции, които излизат в MariaDB 10.4. Там споменахме, че в тази версия ще бъде включена нова версия на Galera Cluster. В тази публикация в блога ще разгледаме функциите на Galera Cluster 26.4.0 (или Galera 4), ще ги разгледаме бързо и ще проучим как те ще повлияят на настройката ви, когато работите с MariaDB Galera Cluster.
Поточно репликация
Galera Cluster в никакъв случай не е заместител на самостоятелния MySQL. Начинът, по който работи сертифицирането на набора за запис, въведе няколко ограничения и крайни случаи, които могат сериозно да ограничат възможността за мигриране в Galera Cluster. Трите най-често срещани ограничения са...
- Проблеми с дълги транзакции
- Проблеми с големи транзакции
- Проблеми с горещи точки в таблиците
Това, което е страхотно да се види, е, че Galera 4 въвежда поточно репликация, което може да помогне за намаляване на тези ограничения. Нека прегледаме текущото състояние малко по-подробно.
Дълго текущи транзакции
В случая говорим за времеви, които определено са проблематични в Галера. Основното нещо, което трябва да разберете, е, че Galera репликира транзакции като набори за запис. Тези набори за запис са сертифицирани от членовете на клъстера, което гарантира, че всички възли могат да прилагат даден набор за запис. Проблемът е, че на локалния възел се създават ключалки, те не се репликират в клъстера, следователно, ако транзакцията ви отнема няколко минути за завършване и ако пишете на повече от един възел на Galera, с времето става все по-вероятно един от останалите възли, някои транзакции ще променят някои от редовете, актуализирани във вашата продължителна транзакция. Това ще доведе до неуспех на сертифицирането и дългосрочната транзакция ще трябва да бъде отменена. Накратко, като се има предвид, че изпращате записи до повече от един възел в клъстера, по-дълга е транзакцията, толкова по-вероятно е сертифицирането да се провали поради някакъв конфликт.
Горещи точки
Под това имаме предвид редове, които често се актуализират. Обикновено това е някакъв брояч, който се актуализира отново и отново. Виновникът за проблема е същият като при дългите транзакции - редовете се заключват само локално. Отново, ако изпращате записи до повече от един възел, е вероятно един и същи брояч да бъде променен едновременно на повече от един възел, което ще доведе до конфликти и ще направи сертифицирането неуспешно.
И за двата проблема има едно решение - можете да изпращате вашите записи само до един възел, вместо да ги разпределяте в целия клъстер. Можете да използвате прокси сървъри за това - ClusterControl разгръща HAProxy и ProxySQL, и двете могат да бъдат конфигурирани така, че записите да се изпращат само до един възел. Ако не можете да изпращате записи само до един възел, трябва да приемете, че от време на време ще виждате конфликти на сертификати и връщане назад. Като цяло приложението трябва да може да обработва връщания от базата данни - няма начин да се заобиколи това, но е още по-важно, когато приложението работи с Galera Cluster.
Все пак изпращането на трафик към един възел не е достатъчно за справяне с третия проблем.
Големи транзакции
Това, което е важно да имате предвид, е, че наборът за запис се изпраща за сертифициране само когато транзакцията приключи. След това наборът за запис се изпраща до всички възли и се извършва процесът на сертифициране. Това води до ограничения за това колко голяма може да бъде една транзакция, тъй като Galera, когато подготвя набор за запис, го съхранява в буфер в паметта. Твърде големите транзакции ще намалят производителността на клъстера. Затова бяха въведени две променливи:wsrep_max_ws_rows, която ограничава броя на редовете на транзакция (въпреки че може да бъде настроена на 0 - неограничена) и, по-важно:wsrep_max_ws_size, която може да бъде настроена до 2 GB. Така че най-голямата транзакция, която можете да изпълните с Galera Cluster, е с размер до 2 GB. Също така, трябва да имате предвид, че сертифицирането и прилагането на голямата транзакция също отнема време, създавайки „закъснение“ – четене след запис, този възел, различен от мястото, където първоначално сте извършили транзакцията, най-вероятно ще доведе до неправилни данни, тъй като транзакцията все още се прилага.
Galera 4 идва с поточно репликация, която може да се използва за смекчаване на всички тези проблеми. Основната разлика ще бъде, че наборът за запис вече може да бъде разделен на части - вече няма да е необходимо да се чака завършването на цялата транзакция, преди данните да бъдат репликирани. Това може да ви накара да се запитате – как изглежда сертифицирането в такъв случай? Накратко, сертифицирането е в движение - всеки фрагмент е сертифициран и всички включени редове са заключени на всички възли в клъстера. Това е сериозна промяна в начина, по който работи Galera - досега заключванията се създаваха локално, като за всички възли ще се създават заключвания за стрийминг репликация. Това помага в случаите, които обсъдихме по-горе - заключването на редове при влизане на фрагменти от транзакции помага да се намали вероятността транзакцията да бъде върната обратно. Конфликтните транзакции, изпълнявани локално, няма да могат да получат нужните им заключвания и ще трябва да изчакат репликационната транзакция да завърши и да освободи заключванията на редовете.
В случай на горещи точки, с поточно репликация е възможно да получите заключванията на всички възли при актуализиране на реда. Други заявки, които искат да актуализират същия ред, ще трябва да изчакат освобождаването на заключването, преди да изпълнят промените си.
Големите транзакции ще се възползват от репликацията на поточно предаване, тъй като вече няма да е необходимо да се чака завършването на цялата транзакция, нито ще бъдат ограничени от размера на транзакцията - големите транзакции ще бъдат разделени на фрагменти. Също така помага за по-добро използване на мрежата – вместо да изпращате 2GB данни наведнъж, същите 2GB данни могат да бъдат разделени на фрагменти и изпратени за по-дълъг период от време.
Има две опции за конфигурация за стрийминг репликация:wsrep_trx_fragment_size, която казва колко голям трябва да бъде фрагментът (по подразбиране е зададен на 0, което означава, че репликацията на поточно предаване е деактивирана) и wsrep_trx_fragment_unit, която казва какъв всъщност е фрагментът. По подразбиране това е байтове, но може да бъде и „инструкции“ или „редове“. Тези променливи могат (и трябва) да бъдат зададени на ниво сесия, което дава възможност на потребителя да реши коя конкретна заявка трябва да бъде репликирана, използвайки стрийминг репликация. Задаването на единица на „изявления“ и размер на 1 позволява например да се използва поточно репликация само за една заявка, която например актуализира гореща точка.
Разбира се, има недостатъци при стартирането на поточно репликацията, главно поради факта, че вече се вземат заключвания на всички възли в клъстера. Ако сте виждали връщане на големи транзакции от векове, сега такава транзакция ще трябва да се върне на всички възли. Очевидно е, че най-добрата практика е да намалите размера на транзакцията, доколкото е възможно, за да избегнете връщания, отнемащи часове. Друг недостатък е, че поради причините за възстановяване при срив, наборите за запис, създадени от всеки фрагмент, се съхраняват в таблицата wsrep_schema.SR на всички възли, което, като че ли, реализира буфер за двойно записване, увеличавайки натоварването на клъстера. Ето защо трябва внимателно да решите коя транзакция трябва да бъде репликирана с помощта на репликация за поточно предаване и, стига да е осъществимо, трябва да се придържате към най-добрите практики за малки, кратки транзакции или разделяне на голямата транзакция на по-малки партиди.
Резервни ключалки
И накрая, потребителите на MariaDB ще могат да се възползват от резервни заключвания за SST. Идеята зад SST, изпълняван с помощта на (за MariaDB) mariabackup, е, че целият набор от данни трябва да бъде прехвърлен в движение, като регистрационните файлове за повторно изпълнение се събират във фонов режим. След това трябва да се придобие глобално заключване, което да гарантира, че няма да се случи запис, трябва да се събере и съхрани крайната позиция на дневника за повторно изпълнение. Исторически погледнато, за MariaDB, заключващата част се извършваше с помощта на FLUSH TABLES WITH READ LOCK, което вършеше своята работа, но при голямо натоварване беше доста трудно да се придобие. Освен това е доста тежък - не само транзакциите трябва да чакат освобождаването на заключването, но също така данните трябва да бъдат изхвърлени на диск. Сега, с MariaDB 10.4, ще бъде възможно да се използва по-малко натрапчиво BACKUP LOCK, което няма да изисква изтриване на данни, само ангажиментите ще бъдат блокирани за продължителността на заключването. Това би трябвало да означава по-малко натрапчиви SST операции, което определено е страхотно да се чуе. Всеки, който трябваше да пусне своя Galera Cluster в авариен режим, на един възел, стискайки палци SST да не повлияе на операциите на клъстера, трябва да бъде повече от щастлив да чуе за това подобрение.
Каузални четения от приложението
Galera 4 въведе три нови функции, които са предназначени да помогнат за добавяне на поддръжка за причинно-следствени четения в приложенията - WSREP_LAST_WRITTEN_GTID(), която връща GTID на последното записване, направено от клиента, WSREP_LAST_SEEN_GTID(), което връща GTID на последната наблюдавана транзакция на запис от клиента и WSREP_SYNC_WAIT_UPTO_GTID(), което ще блокира клиента, докато GTID, предаден на функцията, не бъде записан на възела. Разбира се, можете да наложите причинно-следствени четения в Galera дори сега, но чрез използването на тези функции ще бъде възможно да се внедри безопасно четене след запис в онези части на приложението, където е необходимо, без да е необходимо да се правят промени в конфигурацията на Galera.
Надстройка до MariaDB Galera 10.4
Ако искате да изпробвате Galera 4, той е наличен в последния кандидат за версия на MariaDB 10.4. Според документацията на MariaDB, в този момент няма начин да се направи надстройка на живо от 10.3 Galera до 10.4. Трябва да спрете целия 10.3 клъстер, да го надстроите до 10.4 и след това да го стартирате обратно. Това е сериозен блокер и се надяваме това ограничение да бъде премахнато в една от следващите версии. От изключително значение е да има опция за надграждане на живо и за това както MariaDB 10.3, така и MariaDB 10.4 ще трябва да съществуват съвместно в един и същ клъстер Galera. Друг вариант, който също може да е подходящ, е да настроите асинхронна репликация между стария и новия клъстер Galera.
Наистина се надяваме, че сте харесали този кратък преглед на функциите на MariaDB 10.4 Galera Cluster, с нетърпение очакваме да видим стрийминг репликация в реални производствени среди на живо. Надяваме се също, че тези промени ще помогнат за още по-голямо усвояване на Galera. В крайна сметка, поточно репликацията решава много проблеми, които могат да попречат на хората да мигрират в Galera.
