В настройка на главен-подчинен MySQL 5.7, която използва настройката за полусинхронна репликация по подразбиране за rpl_semi_sync_master_wait_point , срив на главната и преминаването към подчинения се счита за без загуби. Въпреки това, когато катастрофиралият главен обект се върне, може да откриете, че има транзакции, които не присъстват в текущия главен (който преди това е бил подчинен). Това поведение може да е озадачаващо, като се има предвид, че се предполага, че полусинхронната репликация е без загуби, но това всъщност е очаквано поведение в MySQL. Защо точно това се случва, е обяснено подробно в публикацията в блога на Жан-Франсоа Гагне (JF).
Като се има предвид такъв сценарий, документацията на MySQL препоръчва сриваният главен код да бъде изхвърлен и не трябва да се рестартира. Въпреки това, изхвърлянето на сървър като този е скъпо и неефективно. В тази публикация в блога ще обясним подход за откриване и коригиране на транзакции на сривалия се главен сървър на MySQL в настройка на полусинхронна репликация и как да го подредите отново в настройката си главен-подчинен.
Защо е важно да се откриват допълнителни транзакции на възстановения главен файл?
Допълнителните транзакции на възстановения главен файл могат да се проявят по два начина:
1. Грешки при репликацията на MySQL, когато възстановеният главен обект е повторно подчинен
Обикновено това се случва, когато имате първичен ключ с автоматично увеличение. Когато новият главен MySQL вмъкне ред в такава таблица, репликацията ще бъде неуспешна, защото ключът вече съществува на подчинения.
Друг сценарий е, когато приложението ви повтори транзакцията, която е била неуспешна по време на основния срив. На възстановения главен MySQL (който сега е подчинен) тази транзакция действително ще съществува и отново води до грешка при репликация.
Обикновено грешката при репликация на MySQL би изглеждала така:
| [ГРЕШКА] Подчинен SQL за канал '':Работник 5 не успя да изпълни транзакцията 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' в главния регистър mysql-bin.000030, end_log_pos 10262184; Грешка „Дублиране на запис „5018“ за ключ „PRIMARY“ при заявка. База данни по подразбиране:'тест'. Заявка:'вмъкнете в тестови стойности(5018,2019,'item100')', Error_code:1062 |
2. Безшумно несъответствие в данните между новия главен и подчинен MySQL (възстановен главен)
В случаите, когато приложението не опита отново неуспешната транзакция и няма сблъсъци на първичен ключ в бъдеще, грешка при репликация може да не възникне. В резултат на това несъответствието на данните може да остане неоткрито.
И в двата случая по-горе е засегната или високата наличност, или целостта на данните на вашата настройка на MySQL, поради което е толкова важно да откриете това състояние възможно най-рано.
Как да открием допълнителни транзакции на възстановения MySQL Master
Можем да открием дали има допълнителни транзакции на възстановения главен файл, използвайки функцията MySQL GTID (глобален идентификатор на транзакция):
GTID_SUBSET(набор1 ,настройка2 ):Дадени са два набора от глобални идентификатори на транзакции set1 и set2 , връща true, ако всички GTID в set1 също са в set2 . В противен случай връща false.
Нека използваме пример, за да разберем това.
- GTID, зададен на възстановения главен код, чийто UUID е:„54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ е:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- Наборът GTID на новия главен идентификатор, чийто UUID е:„57956099-d01d-11e7-80bc-000d3af97c09 “ е:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af-18c>
Сега, ако извикаме функцията GTID_SUBSET като GTID_SUBSET(GTID набор от възстановен главен, GTID набор от нов главен) , върнатата стойност ще бъде вярна, само ако възстановеният главен файл няма допълнителни транзакции. В нашия пример по-горе, тъй като възстановеният главен код има допълнителни транзакции от 9691 до 9700, резултатът от горната заявка е фалшив.
Повторно подчиняване на сринат #MySQL главен сървър в настройка на полусинхронна репликация Щракнете, за да туитиратеКак да подредите отново възстановения MySQL Master, който има допълнителни транзакции
Въз основа на горната стъпка е възможно да се знае дали възстановеният главен код има допълнителни транзакции и какви са тези транзакции, използвайки функцията GTID:GTID_SUBTRACT(GTID набор от възстановен главен, GTID набор от нов главен).
Възможно е също да извлечете тези допълнителни транзакции от двоичните регистрационни файлове и да ги запишете. Може да е полезно за вашия бизнес екип по-късно да прегледа тези транзакции, за да се уверите, че не губим по невнимание важна бизнес информация, въпреки че не е била ангажирана. След като това бъде направено, имаме нужда от начин да се отървем от тези допълнителни транзакции, така че възстановеният главен обект да може да бъде повторно подчинен без проблеми.
Един от най-простите начини да направите това е да направите резервна моментна снимка на текущия главен и да възстановите данните на текущия подчинен. Не забравяйте, че трябва да запазите UUID на този сървър, както преди. След като възстановите данните, сървърът може да бъде повторно подчинен и той ще започне репликация от точката на възстановената моментна снимка. Скоро отново ще имате здрав роб!
Стъпките по-горе са много досадни, ако трябва да ги изпълнявате ръчно, но напълно управляваната MySQL хостинг услуга на ScaleGrid може да автоматизира целия процес вместо вас, без да е необходима намеса. Ето как работи:
Ако текущият ви главен се срине, ScaleGrid автоматизира процеса на преодоляване на срив и популяризира подходящ подчинен като нов главен. След това старият главен код се възстановява и ние автоматично установяваме дали има допълнителни транзакции по него. Ако има такива, внедряването на MySQL се поставя в деградирало състояние и ние използваме автоматизирани инструменти за извличане и запазване на допълнителните транзакции за ваш преглед. След това нашият екип за поддръжка може да възстанови стария главен сървър в добро състояние и да го постави отново в настройката ви главен-подчинен, така че да имате здравословно внедряване!
Искате ли да опитате? Започнете безплатна 30-дневна пробна версия, за да разгледате всички възможности за управление на база данни MySQL в ScaleGrid.
