Репликацията в MySQL съществува от дълго време и непрекъснато се подобрява през годините. Това е по-скоро еволюция, отколкото революция. Това е напълно разбираемо, тъй като репликацията е важна характеристика, от която мнозина зависят – тя трябва да работи.
В последните версии на MySQL видяхме подобрения в производителността на репликация чрез поддръжка за паралелно прилагане на транзакции. В MySQL 5.6 паралелизирането беше направено на ниво схема - всички транзакции, които са били изпълнени в отделни схеми, могат да бъдат изпълнени наведнъж. Това беше хубаво подобрение за онези натоварвания, които имаха множество схеми на един сървър и натоварването беше разпределено повече или по-малко равномерно между схемите.
В MySQL 5.7 беше добавен друг метод за паралелизиране, така нареченият „логически часовник“. Позволява да получите известно ниво на едновременност на подчинен, дори ако всичките ви данни са били съхранени в една схема. Накратко се основаваше на факта, че някои транзакции ще се извършват заедно поради латентност, добавена от хардуера. Можете дори да добавите това забавяне ръчно, за да постигнете по-добро успоредяване на подчинените с помощта на binlog_group_commit_sync_delay.
Това решение беше наистина хубаво, но не и без недостатъци. Всяко забавяне при извършване на транзакция в крайна сметка може да засегне части от приложението, насочени към потребителя. Разбира се, можете да зададете забавяния в рамките на няколко милисекунди, но дори и тогава това е допълнителна латентност, която забавя приложението.
Подобрения в производителността на репликация в MySQL 8.0
MySQL 8.0, който към момента (август 2017 г.) все още е в бета състояние, носи някои хубави подобрения в репликацията. Първоначално той е разработен за групова репликация (GR), но тъй като GR използва редовна репликация под капака, „нормалната“ MySQL репликация се възползва от него. Подобрението, което споменахме, е информация за проследяване на зависимости, съхранявана в двоичния дневник. Това, което се случва, е, че MySQL 8.0 вече има начин да съхранява информация за това кои редове са били засегнати от дадена транзакция (т.нар. writeset) и сравнява набори за запис от различни транзакции. Това дава възможност да се идентифицират онези транзакции, които не са работили върху едно и също подмножество от редове и следователно те могат да се прилагат паралелно. Това може да позволи да се увеличи нивото на паралелизиране с няколко пъти в сравнение с реализацията от MySQL 5.7. Това, което трябва да имате предвид, е, че в крайна сметка робът ще види различен изглед на данните, такъв, който никога не се е появявал на главния. Това е така, защото транзакциите може да се прилагат в различен ред от този на главния. Това обаче не би трябвало да е проблем. Текущата реализация на многонишкова репликация в MySQL 5.7 също може да причини този проблем, освен ако не активирате изрично slave-preserve-commit-order.
За да контролирате това ново поведение, променлива binlog_transaction_dependency_tracking е въведено. Може да има три стойности:
- COMMIT_ORDER:това е по подразбиране, използва механизма по подразбиране, наличен в MySQL 5.7.
- WRITESET:Позволява по-добро паралелизиране и главният започва да съхранява данни за набора за запис в двоичен дневник.
- WRITESET_SESSION:Това гарантира, че транзакциите ще се изпълняват на подчинения ред и проблемът с подчинен, който вижда състояние на база данни, който никога не е бил виждан на главната, е елиминиран. Намалява паралелизирането, но все пак може да осигури по-добра пропускателна способност от настройките по подразбиране.
Сравнение
През юли, на mysqlhighavailability.com, Витор Оливейра написа публикация, в която се опита да измери производителността на новите режими. Той използва най-добрия сценарий - без никаква издръжливост, за да покаже разликата между стари и нови режими. Решихме да използваме същия подход, този път в по-реална настройка:двоичен дневник, активиран с log_slave_updates. Настройките за издръжливост бяха оставени по подразбиране (така че sync_binlog=1 - това е новото по подразбиране в MySQL 8.0, активиран буфер за двойно записване, активирани контролни суми InnoDB и т.н.) Единственото изключение в издръжливостта беше innodb_flush_log_at_trx_commit, зададено на 2.
Използвахме m4.2xl инстанции, 32G, 8 ядра (така slave_parallel_workers беше настроен на 8). Използвахме и sysbench, oltp_read_write.lua скрипт. 16 милиона реда в 32 таблици бяха съхранени на 1000GB gp2 обем (това е 3000 IOPS). Тествахме производителността на всички режими за 1, 2, 4, 8, 16 и 32 едновременни Sysbench връзки. Процесът беше следният:спиране на подчинения, изпълнение на 100 000 транзакции, стартиране на подчинен и изчисляване на колко време е необходимо за изчистване на забавянето на подчинения.
Първо, ние всъщност не знаем какво се случи, когато sysbench беше изпълнен само с 1 нишка. Всеки тест се изпълнява пет пъти след загряване. Тази конкретна конфигурация беше тествана два пъти - резултатите са стабилни:еднонишковото натоварване беше най-бързо. Ще го разгледаме допълнително, за да разберем какво се е случило.
Освен това, останалите резултати са в съответствие с това, което очаквахме. COMMIT_ORDER е най-бавният, особено за нисък трафик, 2-8 нишки. WRITESET_SESSION обикновено работи по-добре от COMMIT_ORDER, но е по-бавно от WRITESET за нисък едновременен трафик.
Как може да ми помогне?
Първото предимство е очевидно:ако работното ви натоварване е бавно, но вашите подчинени устройства имат склонност да се връщат обратно в репликацията, те могат да се възползват от подобрената производителност на репликация веднага щом главният бъде надстроен до 8.0. Две бележки тук:първо - тази функция е обратно съвместима и 5.7 slave също могат да се възползват от нея. Второ - напомняне, че 8.0 все още е в бета състояние, ние не ви насърчаваме да използвате бета софтуер в производството, въпреки че при крайна нужда това е опция за тестване. Тази функция може да ви помогне не само когато вашите робове изостават. Те може да са напълно настигнати, но когато създадете нов подчинен или преразгледате съществуващ, този подчинен ще изостава. Възможността за използване на режим „WRITESET“ ще направи процеса на осигуряване на нов хост много по-бърз.
Като цяло тази функция ще има много по-голямо въздействие, което може би си мислите. Като се имат предвид всички показатели, показващи регресия в производителността, когато MySQL обработва трафик с нисък паралелизъм, всичко, което може да помогне за ускоряване на репликацията в такива среди, е огромно подобрение.
Ако използвате средни майстори, това също е функция, която трябва да търсите. Всеки междинен главен елемент добавя известна сериализация към начина, по който транзакциите се обработват и изпълняват - в реалния свят работното натоварване на междинен главен адрес почти винаги ще бъде по-малко паралелно, отколкото на главния. Използването на набори за запис за по-добро успоредяване не само подобрява успоредяването на междинния главен, но също така може да подобри паралелизирането на всички негови подчинени устройства. Възможно е дори (въпреки че ще е необходимо сериозно тестване, за да се провери дали всички части пасват правилно) да използвате междинен главен 8.0, за да подобрите производителността на репликация на вашите подчинени (моля, имайте предвид, че MySQL 5.7 slave може да разбира данни за запис и да ги използва, въпреки че не може да го генерира самостоятелно). Разбира се, възпроизвеждането от 8.0 на 5.7 звучи доста сложно (и не само защото 8.0 все още е бета). При някои обстоятелства това може да работи и може да ускори използването на процесора на вашите 5.7 подчинени устройства.
Други промени в MySQL репликацията
Въвеждането на набори за запис, въпреки че е най-интересното, това не е единствената промяна, която се случи с MySQL репликацията в MySQL 8.0. Нека преминем през някои други, също важни промени. Ако случайно използвате главен файл, по-стар от MySQL 5.0, 8.0 няма да поддържа неговия двоичен регистрационен формат. Не очакваме да видим много такива настройки, но ако използвате някакъв много стар MySQL с репликация, определено е време за надграждане.
Стойностите по подразбиране са променени, за да се гарантира, че репликацията е възможно най-безопасна от срив:master_info_repository и relay_log_info_repository са зададени на TABLE. Expire_log_days също е променено - сега стойността по подразбиране е 30. В допълнение към expire_log_days , е добавена нова променлива, binlog_expire_log_seconds , което позволява по-фина политика за ротация на binlog. Някои допълнителни времеви отпечатъци са добавени към двоичния дневник, за да се подобри наблюдаемостта на забавянето на репликацията, като се въвежда микросекундна детайлност.
По всякакъв начин това не е пълен списък с промени и функции, свързани с репликацията на MySQL. Ако искате да научите повече, можете да проверите дневниците за промени в MySQL. Уверете се, че сте прегледали всички тях – досега функциите са добавени във всички версии 8.0.
Както можете да видите, MySQL репликацията все още се променя и става по-добра. Както казахме в началото, процесът трябва да е бавен, но наистина е страхотно да видим какво предстои. Също така е хубаво да видите как работата за груповата репликация се стича и се използва повторно в „обикновената“ MySQL репликация.
