Полусинхронната репликация на MySQL осигурява подобрена цялост на данните, защото когато комитът се върне успешно, се знае, че данните съществуват поне на две места – главното и неговия подчинен. В тази публикация в блога разглеждаме някои от MySQL хостинг конфигурациите, които влияят върху целостта на данните и аспектите на производителността на полусинхронната репликация. Ще използваме InnoDB машина за съхранение и GTID-базирана репликация в набор от реплики с 3 възела (главен и 2 подчинени), което ще гарантира, че има излишък в подчинените. Това означава, че ако има проблеми с един подчинен, можем да се върнем към другия.
Конфигурации, приложими както за главни, така и за подчинени възли
- innodb_flust_log_at_trx_commit =1
- sync_binlog =1
Тези конфигурации гарантират висока устойчивост и настройки за последователност за данните. Това означава, че всяка извършена транзакция е гарантирано, че присъства в двоични регистрационни файлове и също така регистрационните файлове се изхвърлят на диска. Следователно, в случай на прекъсване на захранването или срив на операционната система, последователността на данните на MySQL винаги се запазва.
Конфигурации на главния възел.
- rpl_semi_sync_master_wait_for_slave_count:
Тази опция се използва за конфигуриране на броя на подчинените, които трябва да изпратят потвърждение, преди полусинхронен главен да може да извърши транзакцията. В набора реплики с 3 възела препоръчваме да зададете това на 1, така че винаги да имаме увереност, че данните са налични в поне един подчинен, като същевременно избягваме всякакво въздействие върху производителността, свързано с изчакване на потвърждение от двата подчинени.
- rpl_semi_sync_master_timeout:
Тази опция се използва за конфигуриране на времето, през което полусинхронният главен оператор чака потвърждение на подчинен, преди да се върне обратно в асинхронен режим. Препоръчваме да зададете това на голям брой, така че да няма връщане към асинхронен режим, който след това побеждава нашата цел за целостта на данните. Тъй като работим с 2 подчинени устройства и rpl_semi_sync_master_wait_for_slave_count е настроен на 1, можем да приемем, че поне един от подчинените устройства потвърждава в рамките на разумен период от време, като по този начин се свежда до минимум въздействието върху производителността на тази настройка.
#MySQL Урок:Съображения за целостта на данните и производителността при полусинхронна репликация Щракнете за туитКонфигурации на подчинените възли
В подчинените винаги е важно да се проследяват много точно две позиции:текущата изпълнена позиция на SQL нишката в релейния регистрационен файл и текущата позиция на IO нишката, която показва колко далеч двоичният файл на mater се чете и копира в slave. Последствията от неспазването на тези позиции са съвсем очевидни. Ако има подчинен срив и рестартиране, SQL нишката може да започне да обработва транзакции от грешно изместване или IO нишката може да започне да изтегля данни от грешна позиция в главните двоични регистрационни файлове. И двата случая ще доведат до повреда на данните.
важно е да се гарантира безопасността при срив на подчинените чрез следните конфигурации:
- relay_log_info_repository =TABLE
- relay_log_recovery =ВКЛ.
Задаването на relay_log_info_repository на TABLE ще гарантира, че позицията на SQL нишката се актуализира заедно с всяко извършване на транзакция на подчинения. Въпреки това е трудно да се поддържа точната позиция на IO нишката и да се изравни с диска. Това е така, защото четенето на главния двоичен регистрационен файл и записването в подчинен регистрационен файл не се основава на транзакции. Въздействието върху производителността е много голямо, ако позицията на IO нишката трябва да бъде актуализирана и прехвърлена на диск след всяко записване в регистрите на подчинено реле. По-елегантно решение би било да зададете relay_log_recovery =ON, като в този случай, ако има рестартиране на MySQL, текущите регистрационни файлове на релето ще се приемат за повредени и ще бъдат наскоро изтеглени от главния въз основа на позицията на SQL нишката.
Не на последно място, важно е да се отбележи, че полусинхронната репликация гарантира, че данните току-що са „стигнали“ до един от подчинените преди главния, който извършва транзакцията, и не означава, че транзакциите се извършват на подчинения. Следователно ще бъде добре да се гарантира, че SQL нишката работи с добра производителност. В идеалния случай SQL нишката се движи ръка за ръка с IO нишката, така че можем да имаме ползата от подчинения не само да получава транзакциите, но и да ги извършва. Препоръчително е да използвате многонишкова подчинена конфигурация, за да можем да постигнем повишена производителност на подчинената SQL нишка. Важните конфигурации за многонишкови подчинени устройства са:
- slave_parallel_workers : Задайте това на> 1, за да активирате множество подчинени SQL нишки. Въз основа на броя на нишките, записващи на главния, можем да решим оптимален брой за това, така че подчинената да не изостава.
- slave-parallel-type =LOGICAL_CLOCK
- slave-preserve-commit-order =1
Горните конфигурации ще обещават паралелизъм в подчинения, като в същото време запазват реда на транзакциите, както се вижда на главния.
В обобщение, като използваме горните конфигурации в нашия набор от реплики на MySQL, ние сме в състояние да поддържаме висока цялост на данните заедно с оптимална производителност.
Както винаги, ако имате въпроси, оставете ни коментар, свържете се с нас на @scalegridio в Twitter или ни изпратете имейл до поддръжката @scalegrid.io.
