Replikasyon ng MySQL pagkatapos ng pagkaputol ng VPN: basahin muna ang dalawang yugto

Nagiging pula ang pagsubaybay sa replikasyon kapag bumagsak ang VPN, at ang unang ugali ay i-reset ang isang posisyon. Ang ugaling iyon ang dahilan kung bakit nagiging problema sa datos ang pagkagambala sa network. Walang sinasabi ang bumagsak na landas tungkol sa natanggap o naipatupad ng replika, at iyon ay dalawang yugto na may dalawang kalagayan. Basahin ang mga ito nang hiwalay bago baguhin ang anuman.

Dalawang yugto, dalawang hiwalay na sagot

Ang karaniwang async na replika ay gumagawa ng dalawang trabaho. Kumokonekta ang tagatanggap sa pinagmulan, humihila ng mga pangyayari at isinusulat ang mga ito nang lokal sa relay log. Binabasa ng tagapagpatupad ang log na iyon at isinasagawa ang mga pangyayari sa replika. Kapag naputol ang landas, agad na humihinto ang tagatanggap habang ang tagapagpatupad ay nagpapatuloy sa pagproseso ng naipon na nasa disk. Kaya ang isang pagkagambala ay lumilikha ng dalawang magkaibang tanong: bumalik ba ang koneksyon, at naipatupad ba ang naipon na trabaho? Kung ituturing silang isang tanong, pinagsasama ang dalawang kalagayan sa isang nakaliligaw na sagot.

Sinasabi ng paggaling ng tagatanggap na buhay ang landas. Wala itong sinasabi tungkol sa kung gaano kalayo ang naabot ng tagapagpatupad, o kung nakatagpo ito ng error habang nakadiskonekta.

Basahin ang channel gamit ang tamang pahayag

Sa MySQL 8.4, nagbabalik ang SHOW REPLICA STATUS ng isang hilera bawat naka-configure na channel, kaya basahin ang hilera ng channel na tinutukoy mo at hindi ang una sa listahan. Hinihiwalay ng Replica_IO_Running ang konektadong tagatanggap mula sa kumokonekta o huminto, at inilalarawan ng Replica_SQL_Running ang tagapagpatupad. Basahin din ang mga column ng error sa tabi nila, dahil ang tagatanggap na muling kumonekta at agad na nabigo ay nag-iiwan ng mensahe na walang bandila ng estado ang magpapakita. Gumagamit ang mas lumang mga release ng ibang mga pangalan ng column, kaya huwag isalin ang lumang resipe sa pamamagitan lamang ng pagpapalit ng pangalan ng mga utos.

Tingnan din ang pagkakakilanlan ng pinagmulan at anumang naka-configure na filter. Ang replikang nakaturo sa maling pinagmulan, o nasala nang mas makitid kaysa sa inaakala mo, ay nag-uulat ng kalusugan habang nire-replika ang iba sa inaasahan mo.

Bakit maaaring magsinungaling ang zero na delay

Inihahambing ng halaga ng delay ang timestamp ng huling naipatupad na pangyayari sa kasalukuyang oras. Kapag huminto ang tagatanggap nang isang oras, maaaring tapusin ng tagapagpatupad ang naipon at maabot ang dulo ng natanggap, at bababa ang bilang sa zero kahit na ang replika ay isang oras na nasa likod ng pinagmulan. Sinusukat ng sukatan ang pila ng tagapagpatupad, hindi ang pagiging bago ng replika.

Sa halip, ihambing ang mga naisagawang transaksyon sa kung ano ang mayroon ang pinagmulan. Ang paghahambing na iyon ay nakakayanan ang natigil na tagatanggap.

Ang pagpapanatili ang nagtatakda ng tunay na window ng pagbawi

Kailangan ng paghabol na hawak pa ng pinagmulan ang mga transaksyong kailangan ng replika. Kapag naalis na ang mga iyon, hindi na makuha ng replika ang mga ito, at walang dami ng muling pagkonekta ang makakabago niyon.

Sa GTID auto-positioning, malinaw ang pagpalya: humihingi ang replika ng kasaysayang wala nang hawak ang pinagmulan at tumatanggi itong magpatuloy. Ang mga opsyon noon ay kunin ang nawawalang mga pangyayari mula sa pinagmulang mayroon pa ng mga ito, o muling itayo mula sa backup at hayaang humabol ito. Ang laktawan ang agwat ay hindi paghabol, at nag-iiwan ito ng replikang tahimik na hindi kumpleto ang datos. Plano ang window sa pamamagitan ng paghahambing ng inaasahang tagal ng pagkagambala sa pagpapanatili ng binary log sa pinagmulan at sa bilis ng pagbabago, dahil ang tatlong bilang na iyon ang nagpapasya kung ang isang pagkagambala ay mababawi pa.

I-verify ang paghabol, hindi ang kulay ng indicator

Ibalik ang landas, kasama ang paglutas ng pangalan at seguridad ng transportasyon, pagkatapos obserbahan kung muling kumokonekta ang umiiral na channel ayon sa sarili nitong patakaran. Bigyan ito ng tinukoy na agwat bago ka manghimasok, at itala ang progreso ng pagtanggap at pagpapatupad sa dalawang dulo ng agwat na iyon. Ang channel na nag-restart at ang channel na napapanahon ay magkaibang natuklasan.

Kumpirmahin na naabot ng tagapagpatupad ang kasalukuyang posisyon ng pinagmulan, hindi lamang ang dulo ng lumang naipon. Tiyakin na walang error na naghihintay sa tagapagpatupad, dahil ang isang nabigong pangyayari ay humihinto sa progreso habang ang tagatanggap ay patuloy na nag-uulat ng koneksyon. Pagkatapos itala ang ebidensya: pangalan ng channel, dalawang kalagayan ng yugto, ang naisagawang posisyon at ang oras. Ang berdeng indicator ay isang pag-aangkin; ang posisyon ay isang katotohanan.