MySQL репликација након прекида VPN-а: прво прочитајте обе фазе

Надгледање репликације постаје црвено када VPN падне, а инстинкт је ресетовати позицију. Тај инстинкт је начин на који мрежни прекид постаје проблем са подацима. Прекинут пут не говори ништа о томе шта је реплика примила или применила, а то су две фазе са два стања. Прочитајте их одвојено пре него што било шта промените.

Две фазе, два одвојена одговора

Уобичајена асинхрона реплика обавља два посла. Пријемник се повезује на извор, повлачи догађаје и записује их локално у relay лог. Извршилац чита тај лог и изводи догађаје на реплици. Када се пут прекине, пријемник се одмах зауставља, док извршилац наставља да обрађује заостатак који је већ на диску. Један прекид зато ствара два различита питања: да ли се веза вратила и да ли је накупљени рад примењен? Ако их третирамо као једно питање, два стања се просечно стапају у обмањујући одговор.

Опоравак пријемника говори да је пут активан. Не говори ништа о томе колико извршилац заостаје, ни да ли је наишао на грешку док је био одспојен.

Читајте канал правом наредбом

У MySQL 8.4 SHOW REPLICA STATUS враћа један ред по конфигурисаном каналу, па читајте ред канала који желите, а не први на списку. Replica_IO_Running разликује повезани пријемник од оног који се повезује или је заустављен, а Replica_SQL_Running описује извршилац. Читајте и колоне са грешкама поред њих, јер пријемник који се поново повеже и одмах падне оставља поруку коју ниједна ознака стања неће показати. Старија издања користе друга имена колона, па не преводите стари рецепт само преименовањем наредби.

Проверите и идентитет извора те све конфигурисане филтере. Реплика усмерена на погрешан извор или филтрирана уже него што мислите пријављује здравље док реплицира нешто друго од очекиваног.

Зашто број нутог заостатка може да лаже

Вредност заостатка упоређује временску ознаку последњег примењеног догађаја са тренутним временом. Када је пријемник стајао сат времена, извршилац може да обради заостатак и дође до краја онога што је примио, а тада број пада на нулу иако реплика заостаје сат за извором. Мера мери ред извршиоца, а не ажурност реплике.

Уместо тога упоредите извршене трансакције са оним што извор има на располагању. То поређење преживљава заустављени пријемник.

Стварни прозор опоравка одређује задржавање

Сустизање захтева да извор још држи трансакције које реплика треба. Када се оне уклоне, реплика их не може дохватити и никакво поновно повезивање то не мења.

Са GTID аутоматским позиционирањем квар је јасан: реплика тражи историју коју извор више не држи и одбија да настави. Опције су тада узети догађаје који недостају са извора који их још има или поново изградити из резервне копије и пустити је да сустигне. Прескакање празнине није сустизање и оставља реплику чији су подаци тихо непотпуни. Планирајте прозор упоређивањем очекиваног трајања прекида са задржавањем бинарног дневника на извору и брзином промена, јер та три броја одлучују да ли је прекид уопште надокнадив.

Проверите сустизање, а не боју показатеља

Вратите пут, укључујући разрешавање имена и безбедност преноса, па гледајте да ли се постојећи канал сам поново повезује по својој политици. Дајте му одређени интервал пре интервенције и забележите напредак пријема и примене на оба краја тог интервала. Канал који се поново покреће и канал који је ажуран различити су налази.

Потврдите да је извршилац достигао тренутну позицију извора, а не само крај старог заостатка. Проверите не чека ли у извршиоцу грешка, јер један неуспели догађај зауставља напредак док пријемник наставља да извештава о повезаности. Затим забележите доказе: назив канала, стања оба ступња, извршену позицију и време. Зелена ознака је тврдња; позиција је чињеница.