Рэплікацыя MySQL пасля абрыву VPN: спачатку прачытайце абодва этапы

Маніторынг рэплікацыі чырванее, калі падае VPN, і першы інстынкт — скінуць пазіцыю. Менавіта гэты інстынкт ператварае сеткавы перапынак у праблему з данымі. Абрынуты шлях нічога не кажа пра тое, што рэпліка атрымала або ўжыла, а гэта два этапы з двума станамі. Чытайце іх асобна, перш чым нешта змяняць.

Два этапы, два асобныя адказы

Звычайная асінхронная рэпліка выконвае дзве працы. Атрымальнік злучаецца з крыніцай, выцягвае падзеі і запісвае іх у лакальны рэлей-лог. Ужывальнік чытае гэты рэлей-лог і выконвае падзеі на рэпліцы. Калі шлях абрываецца, атрымальнік спыняецца імгненна, а ўжывальнік працягвае апрацоўваць той назапашаны аб'ём, што ўжо ёсць на дыску. Такім чынам, адзін перапынак стварае два розныя пытанні: ці вярнулася злучэнне і ці ўжыта назапашаная праца? Калі разглядаць іх як адно пытанне, два станы ўсярэдніваюцца ў памылковы адказ.

Аднаўленне атрымальніка кажа, што шлях працуе. Яно нічога не кажа пра тое, наколькі адстаў ужывальнік, і ці сутыкнуўся ён з памылкай падчас адключэння.

Чытайце канал правільнай камандай

У MySQL 8.4 SHOW REPLICA STATUS вяртае адзін радок на кожны наладжаны канал, таму чытайце радок патрэбнага вам канала, а не першы ў спісе. Replica_IO_Running адрознівае падключаны атрымальнік ад таго, што падключаецца або спынены, а Replica_SQL_Running апісвае ўжывальнік. Чытайце слупкі памылак побач з імі, бо атрымальнік, які перападключаецца і адразу падае, пакідае паведамленне, якога не пакажа ніводны сцяг стану. Старэйшыя выпускі выкарыстоўваюць іншыя назвы слупкоў, таму не перакладайце стары рэцэпт, проста пераймяноўваючы каманды.

Праверце таксама ідэнтычнасць крыніцы і любыя наладжаныя фільтры. Рэпліка, накіраваная на няправільную крыніцу або адфільтраваная вузей, чым вы думаеце, паведамляе пра здароўе, рэплікуючы не тое, чаго вы чакаеце.

Чаму нулявая затрымка можа хлусіць

Значэнне затрымкі параўноўвае адзнаку часу апошняй ужытай падзеі з бягучым часам. Калі атрымальнік быў спынены гадзіну, ужывальнік можа апрацаваць назапашанае і дасягнуць канца атрыманага, і тады лік падае да нуля, хоць рэпліка адстае ад крыніцы на гадзіну. Метрыка вымярае чаргу ўжывальніка, а не актуальнасць рэплікі.

Параўнайце замест гэтага выкананыя транзакцыі з тым, што мае крыніца. Такое параўнанне вытрымлівае спынены атрымальнік.

Сапраўднае акно аднаўлення вызначае захаванне

Каб дагнаць, крыніца павінна яшчэ захоўваць транзакцыі, патрэбныя рэпліцы. Пасля іх выдалення рэпліка не можа іх загрузіць, і ніякая колькасць перападключэнняў гэтага не зменіць.

З аўтапазіцыянаваннем GTID збой відавочны: рэпліка запытвае гісторыю, якой крыніца ўжо не мае, і адмаўляецца працягваць. Тады варыянты — атрымаць адсутныя падзеі з крыніцы, якая іх яшчэ мае, або перабудаваць з рэзервовай копіі і даць ёй дагнаць. Прапускаць разрыў — не даганяць, і гэта пакідае рэпліку, чые даныя ціха няпоўныя. Плануйце акно, параўноўваючы чаканую працягласць перапынку з захаваннем бінарнага лога на крыніцы і хуткасцю змен, бо гэтыя тры лікі вырашаюць, ці паддаецца перапынак аднаўленню наогул.

Правярайце дагон, а не колер індыкатара

Аднавіце шлях, уключаючы развязанне імён і бяспеку транспарту, затым назірайце, ці перападключыцца існуючы канал паводле ўласнай палітыкі. Дайце яму вызначаны інтэрвал перад умяшаннем і запішыце прагрэс прыёму і ўжывання на абодвух канцах гэтага інтэрвалу. Канал, які перазапускаецца, і канал, які актуальны, — розныя высновы.

Пацвердзіце, што ўжывальнік дасягнуў бягучай пазіцыі крыніцы, а не проста канца старога назапашвання. Праверце, што ва ўжывальніку не чакае памылка, бо адна няўдалая падзея спыняе прагрэс, пакуль атрымальнік працягвае паведамляць пра злучэнне. Затым запішыце доказы: назву канала, станы абодвух этапаў, выкананую пазіцыю і час. Зялёны індыкатар — гэта заява; пазіцыя — факт.