Предихме блогове за това какво е новото в MySQL Galera Cluster 4.0, обработката на големи транзакции с поточно репликация и MariaDB 10.4 и представихме някои ръководства за използването на новата функция за поточно репликация в част 1 и част 2 серии.
Преместването на вашата технология за база данни от MySQL Replication към MySQL Galera Cluster изисква от вас да имате правилните умения и разбиране за това, което правите, за да бъдете успешни. В този блог ще споделим някои съвети за мигриране от настройка на MySQL Replication към MySQL Galera Cluster 4.0.
Разликите между MySQL репликацията и клъстера Galera
Ако все още не сте запознати с Galera, ви предлагаме да прегледате нашия урок на Galera Cluster за MySQL. Galera Cluster използва съвсем различно ниво на репликация, базирано на синхронна репликация, за разлика от MySQL репликацията, която използва асинхронна репликация (но може да бъде конфигурирана и за постигане на полусинхронна репликация).
Galera Cluster също поддържа репликация с няколко главни. Той е способен на неограничено паралелно прилагане (т.е. „паралелна репликация“), мултикаст репликация и автоматично предоставяне на възли.
Основният фокус на Galera Cluster е последователността на данните, докато при MySQL репликацията е склонна към несъответствие на данните (което може да бъде избегнато с най-добри практики и правилна конфигурация, като налагане само за четене на подчинените, за да се избегне нежелани записи в подчинените).
Въпреки че транзакциите, получени от Galera, се прилагат или към всеки възел, или изобщо не се прилагат, всеки от тези възли удостоверява репликирания набор за запис в опашката на приложението (извършване на транзакции), което също включва информация за всички заключвания, които са били държани от базата данни по време на транзакцията. Тези набори за запис, след като не са идентифицирани конфликтни заключвания, се прилагат. До този момент транзакциите се считат за ангажирани и продължават да ги прилагат към пространството за таблици. За разлика от асинхронната репликация, този подход се нарича още виртуално синхронна репликация, тъй като записването и записването се извършват в логически синхронен режим, но действителното записване и записване в пространството за таблици се случва независимо и става асинхронно на всеки възел.
За разлика от MySQL репликацията, клъстерът Galera е истински мулти-главен, многонишков подчинен, чисто горещ режим на готовност, без нужда от главен отказ или разделяне на четене-запис. Въпреки това, мигрирането към Galera Cluster не означава автоматичен отговор на вашите проблеми. Galera Cluster поддържа само InnoDB, така че може да има промени в дизайна, ако използвате MyISAM или Memory механизми за съхранение.
Преобразуване на не-InnoDB таблици в InnoDB
Galera Cluster ви позволява да използвате MyISAM, но не е предназначен за това Galera Cluster. Galera Cluster е проектиран да прилага стриктно съгласуваност на данните във всички възли в клъстера и това изисква силна ACID съвместима база данни. InnoDB е двигател, който има толкова силни възможности в тази област и се препоръчва да използвате InnoDB; особено когато се занимавате с транзакции.
Ако използвате ClusterControl, можете лесно да се възползвате от определянето(ите) на вашата база данни за всякакви MyISAM таблици, предоставени от Performance Advisors. Можете да намерите това в раздела Производителност → Съветници. Например,
Ако имате нужда от MyISAM и MEMORY таблици, все още можете да го използвате, но направете уверете се, че вашите данни, които не трябва да се репликират. Можете да използвате данните си, съхранени само за четене, и да използвате „СТАРТ НА ТРАНЗАКЦИЯТА САМО ЧЕТЕНЕ“, където е подходящо.
Добавяне на първични ключове към вашите InnoDB таблици
Тъй като Galera Cluster поддържа само InnoDB, е много важно всичките ви таблици да имат клъстериран индекс (наричан още първичен ключ или уникален ключ). За да получите най-добра производителност от заявки, вмъквания и други операции с база данни, е много важно да дефинирате всяка таблица с уникален ключ(ове), тъй като InnoDB използва клъстерирания индекс за оптимизиране на най-често срещаните операции за търсене и DML за всяка таблица . Това помага за избягване на продължителни заявки в клъстера и е възможно да забави операциите за запис/четене в клъстера.
В ClusterControl има съветници, които могат да ви уведомят за това. Например, във вашия MySQL репликация главен/подчинен клъстер, вие ще получите аларма от или преглед от списъка със съветници. Примерната екранна снимка по-долу разкрива, че нямате таблици, които да нямат първичен ключ:
Идентифициране на главен (или активен записващ) възел
Galera Cluster е чисто истинска репликация с няколко главни. Това обаче не означава, че всички сте свободни да пишете към който възел искате да насочите. Едно нещо, което трябва да идентифицирате, е, че когато пишете на различен възел и ще бъде открита конфликтна транзакция, ще попаднете в проблем със застой точно както по-долу:
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;Проблемът с записването на множество възли без идентифициране на текущ активен възел за запис, в крайна сметка ще се сблъскате с тези проблеми, които са много често срещани проблеми, които съм виждал, когато използвам Galera Cluster при писане на множество възли в по същото време. За да избегнете това, можете да използвате подхода за настройка с един главен:
От документацията,
За да облекчите контрола на потока, можете да използвате настройките по-долу:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Гореното изисква рестартиране на сървъра, тъй като fc_master_slave не е динамичен.
Активиране на режима за отстраняване на грешки за регистриране на конфликти или блокирания
Отстраняването на грешки или проследяването на проблеми с вашия Galera Cluster е много важно. Заключването в Galera се реализира по различен начин в сравнение с MySQL репликацията. Той използва оптимистично заключване, когато се занимава с транзакции в целия клъстер. За разлика от MySQL репликацията, тя има само песимистично заключване, което не знае дали има същата или конфликтна транзакция, която се изпълнява в ко-мастер при настройка с множество главни. Galera все още използва песимистично заключване, но на локалния възел, тъй като се управлява от InnoDB, което е поддържаната машина за съхранение. Galera използва оптимистично заключване, когато отива към други възли. Това означава, че не се правят проверки с други възли в клъстера, когато се постигнат локални заключвания (песимистично заключване). Galera предполага, че след като транзакцията премине фазата на комит в механизма за съхранение и другите възли са информирани, всичко ще бъде наред и няма да възникнат конфликти.
На практика е най-добре да активирате wsrep_logs_conflicts. Това ще регистрира подробностите за конфликтни MDL, както и заключване на InnoDB в клъстера. Активирането на тази променлива може да бъде зададено динамично, но имайте предвид, след като това е активирано. Той многословно ще попълни вашия регистрационен файл за грешки и може да запълни вашия диск, след като размерът на файла с регистрационния файл за грешки е твърде голям.
Бъдете внимателни с вашите DDL заявки
За разлика от MySQL репликацията, изпълнението на оператор ALTER може да засегне само входящите връзки, които изискват достъп или препратка към тази таблица, насочена от вашия оператор ALTER. Може също да засегне подчинените, ако масата е голяма и може да доведе до забавяне на подчинените. Въпреки това, записите до вашия главен герой няма да бъдат блокирани, стига вашите заявки да не са в конфликт с текущия ALTER. Това обаче не е съвсем така, когато изпълнявате вашите DDL изрази като ALTER с Galera Cluster. Инструкциите ALTER могат да доведат до проблеми като Galera Cluster, блокиран поради заключване в целия клъстер или контролът на потока започва да отпуска репликацията, докато някои възли се възстановяват от големи записи.
В някои ситуации може в крайна сметка да имате престой във вашия Galera Cluster, ако тази таблица е твърде голяма и е основна и жизненоважна таблица за вашето приложение. Това обаче може да се постигне без прекъсвания. Както Рик Джеймс посочи в своя блог, можете да следвате препоръките по-долу:
RSU срещу TOI
- Подвижно надграждане на схема =ръчно правете един възел (офлайн) в даден момент
- Обща изолация на поръчката =Galera се синхронизира, така че да се извършва едновременно (в последователността на репликация) на всички възли. RSU и TOI
Внимание:Тъй като няма начин да синхронизирате клиентите с DDL, трябва да се уверите, че клиентите са доволни или от старата, или от новата схема. В противен случай вероятно ще трябва да премахнете целия клъстер, като едновременно с това превключвате както схемата, така и клиентския код.
Бърз DDL може да се направи и чрез TOI. Това е примерен списък на такива:
- СЪЗДАВАНЕ/ИЗПУСКАНЕ/ПРЕИМЕНУВАНЕ НА БАЗА ДАННИ/ТАБЛИЦА
- ПРОМЕНИ, за да промените ПО ПОДРАЗБИРАНЕ
- ALTER, за да промените дефиницията на ENUM или SET (вижте предупрежденията в ръководството)
- Някои БЪРЗИ ПРОМЕНИ НА PARTITION ALTER.
- ИЗПУСКАНЕ ИНДЕКС (различен от ПЪРВИЧЕН КЛЮЧ)
- ДА ДОБАВИ ИНДЕКС?
- Други ALTER на „малки“ маси.
- Тъй като 5.6 и особено 5.7 има много случаи ALTER ALGORITHM=INPLACE, проверете кои ALTER трябва да се правят по какъв начин.
В противен случай използвайте RSU. Направете следното поотделно за всеки възел:
SET GLOBAL wsrep_OSU_method='RSU';Това също така изважда възела от клъстера.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Връща се обратно, което води до повторно синхронизиране (надявам се бърз IST, а не бавен SST)
Запазете последователността на вашия клъстер
Galera Cluster не поддържа филтри за репликация като binlog_do_db или binlog_ignore_db, тъй като Galera не разчита на двоичен журнал. Той разчита на файла с пръстен буфер, наречен също GCache, който съхранява набори за запис, които се репликират по протежение на клъстера. Не можете да приложите никакво непоследователно поведение или състояние на такива възли на базата данни.
Galera, от друга страна, стриктно прилага последователността на данните в клъстера. Все още е възможно да има несъответствие, където редове или записи не могат да бъдат намерени. Например, задаването на вашата променлива wsrep_OSU_method или RSU, или TOI за вашите DDL ALTER изрази може да доведе до непоследователно поведение. Вижте този външен блог от Percona, който обсъжда несъответствието с Galera с TOI срещу RSU.
Задаването на wsrep_on=OFF и последващото изпълнение на DML или DDL заявки може да бъде опасно за вашия клъстер. Вие също трябва да прегледате вашите съхранени процедури, тригери, функции, събития или изгледи, ако резултатите не зависят от състоянието или средата на възела. Когато определен(и) възел(и) може да бъде(и) непоследователен(и), това потенциално може да доведе до срив на целия клъстер. След като Galera открие непоследователно поведение, Galera ще се опита да напусне клъстера и да прекрати този възел. Следователно е възможно всички възли да са непоследователни, оставяйки ви в състояние на дилема.
Ако възел на Galera Cluster също претърпи срив, особено в период с висок трафик, по-добре е да не стартирате веднага възела. Вместо това извършете пълен SST или донесете нов екземпляр възможно най-скоро или след като трафикът намалее. Възможно е възелът да доведе до непоследователно поведение, което може да е повредило данните.
Разделете големи транзакции и определете дали да използвате поточно репликация
Нека да преминем направо към този. Една от най-големите промени, особености на Galera Cluster 4.0, е стрийминг репликацията. Минали версии на Galera Cluster 4.0, той ограничава транзакциите <2GiB, което обикновено се контролира от променливи wsrep_max_ws_rows и wsrep_max_ws_size. От Galera Cluster 4.0 можете да изпращате> 2GiB транзакции, но трябва да определите колко големи фрагментите трябва да бъдат обработени по време на репликацията. Тя трябва да бъде зададена от сесия и единствените променливи, за които трябва да се грижите, са wsrep_trx_fragment_unit и wsrep_trx_fragment_size. Деактивирането на поточно репликацията е просто, тъй като задаване на wsrep_trx_fragment_size = 0 ще го направи. Обърнете внимание, че репликирането на голяма транзакция също има допълнителни разходи за подчинените възли (възли, които се репликират срещу текущия активен записващ/главен възел), тъй като логовете ще бъдат записани в таблицата wsrep_streaming_log в базата данни MySQL.
Още нещо, което трябва да добавите, тъй като имате работа с голяма транзакция, значително е, че транзакцията ви може да отнеме известно време, за да завърши, така че трябва да се вземе предвид настройката на променливата innodb_lock_wait_timeout high. Задайте това чрез сесия в зависимост от времето, което преценявате, но по-голямо от времето, което очаквате да завърши, в противен случай увеличете времето за изчакване.
Препоръчваме ви да прочетете този предишен блог за поточно репликацията в действие.
Репликиране на изявления GRANTs
Ако използвате GRANTs и свързани операции, действайте върху таблиците MyISAM/Aria в базата данни `mysql`. Инструкциите GRANT ще бъдат репликирани, но основните таблици – не. Това означава, че INSERT INTO mysql.user ... няма да се репликира, защото таблицата е MyISAM.
Въпреки това, горното може да не е вярно вече, тъй като Percona XtraDB Cluster(PXC) 8.0 (понастоящем експериментален), тъй като таблиците със схеми на mysql са преобразувани в InnoDB, докато в MariaDB 10.4 някои от таблиците все още са във формат Aria, но други са в CSV или InnoDB. Трябва да определите каква версия и доставчик на Galera имате, но най-добре е да избягвате използването на DML изрази, отнасящи се до mysql схема. В противен случай може да получите неочаквани резултати, освен ако не сте сигурни, че това е PXC 8.0.
Транзакциите XA, ЗАКЛЮЧВАНЕ/ОТКЛЮЧВАНЕ НА ТАБЛИЦИ, GET_LOCK/RELEASE_LOCK не се поддържат
Galera Cluster не поддържа XA Transactions, тъй като XA Transactions обработва връщане назад и извършва по различен начин. Инструкциите LOCK/UNLOCK или GET_LOCK/RELEASE_LOCK са опасни за прилагане или използване с Galera. Може да изпитате срив или ключалки, които не могат да бъдат убити и да останат заключени. Например,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5Тази транзакция вече е отключена и дори убита, но без резултат. Предлагаме ви да преработите своя клиент на приложението и да се отървете от тези функции, когато мигрирате към Galera Cluster.
Стабилността на мрежата е ЗАДЪЛЖИТЕЛНА!!!
Galera Cluster може да работи дори с топология между WAN или между географска топология без никакви проблеми (вижте този блог за внедряването на междугео топология с Galera). Въпреки това, ако вашата мрежова свързаност между всеки възел не е стабилна или периодично намалява за неподозирано време, това може да бъде проблематично за клъстера. Най-добре е да имате клъстер, работещ в частна и локална мрежа, където всеки от тези възли е свързан. Когато проектирате възел като аварийно възстановяване, планирайте да създадете клъстер, ако те са в различен регион или географско положение. Може да започнете да четете предишния ни блог, Използване на MySQL Galera Cluster Replication за създаване на гео-разпределен клъстер:Част първа, тъй като това може да ви помогне най-добре да решите вашата топология на Galera Cluster.
Друго нещо, което трябва да добавите относно инвестирането на вашия мрежов хардуер, би било проблематично, ако скоростта на мрежов трансфер ви осигурява по-ниска скорост по време на възстановяване на инстанция по време на IST или по-лошо при SST, особено ако вашият набор от данни е огромен . Може да отнеме дълги часове мрежов трансфер и това може да повлияе на стабилността на вашия клъстер, особено ако имате клъстер с 3 възела, докато 2 възела не са налични, където тези 2 са донор и съединител. Обърнете внимание, че по време на фазата на SST възлите DONOR/JOINER не могат да се използват, докато накрая не успеят да се синхронизират с основния клъстер.
В предишната версия на Galera, когато става въпрос за избор на възел на донор, донорът за прехвърляне на моментна снимка на състоянието (SST) беше избран на случаен принцип. В Glera 4 той е много по-добре подобрен и има възможността да избира правилния донор в рамките на клъстера, тъй като ще благоприятства донор, който може да осигури инкрементален трансфер на състояние (IST) или да избере донор в същия сегмент. Като алтернатива можете да зададете променлива wsrep_sst_donor на правилния донор, който искате винаги да избирате.
Архивирайте данните си и направете строги тестове по време на миграция и преди производството
След като сте готови и сте решили да опитате да мигрирате данните си към Galera Cluster 4.0, уверете се, че винаги имате подготвен архив. Ако сте опитали ClusterControl, правенето на резервни копия ще бъде по-лесно за това.
Уверете се, че мигрирате към правилната версия на InnoDB и не забравяйте винаги да прилагате и стартирате mysql_upgrade, преди да направите теста. Уверете се, че всичките ви тестове преминават желания резултат, от който MySQL репликацията може да ви предложи. Най-вероятно няма разлика с механизма за съхранение на InnoDB, който използвате в MySQL Replication Cluster спрямо MySQL Galera Cluster, стига препоръките и съветите да са приложени и подготвени предварително.
Заключение
Мигрирането към Galera Cluster 4.0 може да не е желаното от вас технологично решение за база данни. Въпреки това, това не ви отвлича да използвате Galera Cluster 4.0, стига неговите специфични изисквания да могат да бъдат подготвени, настроени и предоставени. Galera Cluster 4.0 вече се превърна в много мощен жизнеспособен избор и опция, особено на високодостъпна платформа и решение. Също така ви предлагаме да прочетете тези външни блогове за предупрежденията на Galera или ограниченията на Galera Cluster или това ръководство от MariaDB.
