VPN કાપ પછી MySQL રેપ્લિકેશન: પહેલાં બંને તબક્કા વાંચો

VPN પડે ત્યારે રેપ્લિકેશન મોનિટરિંગ લાલ થાય છે, અને પ્રથમ વૃત્તિ સ્થિતિ રીસેટ કરવાની હોય છે. એ જ વૃત્તિ નેટવર્ક કાપને ડેટા સમસ્યામાં ફેરવે છે. તૂટેલો માર્ગ રેપ્લિકાએ શું મેળવ્યું કે લાગુ કર્યું તે વિશે કંઈ કહેતું નથી, અને તે બે સ્થિતિવાળા બે તબક્કા છે. કંઈપણ બદલતાં પહેલાં તેમને અલગ વાંચો.

બે તબક્કા, બે અલગ જવાબો

સામાન્ય અસિંક્રોનસ રેપ્લિકા બે કામ કરે છે. રીસીવર સ્રોત સાથે જોડાય છે, ઘટનાઓ ખેંચે છે અને તેમને સ્થાનિક રીતે રિલે લોગમાં લખે છે. એપ્લાયર એ રિલે લોગ વાંચે છે અને ઘટનાઓને રેપ્લિકા પર ચલાવે છે. માર્ગ તૂટે ત્યારે રીસીવર તરત અટકે છે, જ્યારે એપ્લાયર ડિસ્ક પર પહેલેથી રહેલા બેકલોગ પર કામ ચાલુ રાખે છે. તેથી એક કાપ બે અલગ પ્રશ્નો ઊભા કરે છે: જોડાણ પાછું આવ્યું છે, અને એકઠું થયેલું કામ લાગુ થયું છે? તેમને એક પ્રશ્ન તરીકે લેવાથી બે સ્થિતિ ભેગી થઈને ભ્રામક જવાબ બને છે.

રીસીવરની પુનઃપ્રાપ્તિ કહે છે કે માર્ગ ચાલુ છે. તે એ નથી કહેતું કે એપ્લાયર કેટલું પાછળ છે, કે ડિસ્કનેક્ટ રહીને તેને ભૂલ મળી કે નહીં.

યોગ્ય સ્ટેટમેન્ટ સાથે ચેનલ વાંચો

MySQL 8.4 માં SHOW REPLICA STATUS દરેક રૂપરેખાંકિત ચેનલ માટે એક પંક્તિ આપે છે, તેથી યાદીમાંની પહેલી પંક્તિને બદલે તમે જે ચેનલ ધારો છો તેની પંક્તિ વાંચો. Replica_IO_Running જોડાયેલા રીસીવરને જોડાઈ રહેલા કે અટકેલા રીસીવરથી અલગ પાડે છે, અને Replica_SQL_Running એપ્લાયરનું વર્ણન કરે છે. તેમની બાજુમાં ભૂલના કૉલમ વાંચો, કારણ કે ફરી જોડાઈને તરત નિષ્ફળ જતું રીસીવર એવો સંદેશ છોડે છે જે કોઈ સ્ટેટસ ફ્લેગ બતાવશે નહીં. જૂની આવૃત્તિઓ અલગ કૉલમ નામો વાપરે છે, તેથી ફક્ત આદેશોના નામ બદલીને જૂની રેસીપીનું ભાષાંતર ન કરો.

સ્રોતની ઓળખ અને રૂપરેખાંકિત ફિલ્ટર પણ તપાસો. ખોટા સ્રોત તરફ નિર્દેશિત, અથવા તમે ધારો તેના કરતાં સાંકડું ફિલ્ટર કરેલી રેપ્લિકા સ્વસ્થતા જાહેર કરે છે જ્યારે તે તમે અપેક્ષા રાખો તેનાથી અલગ કંઈક રેપ્લિકેટ કરે છે.

શૂન્ય લેગનો આંકડો કેમ જૂઠું બોલી શકે

લેગ મૂલ્ય છેલ્લી લાગુ થયેલી ઘટનાની સમયમુદ્રાને વર્તમાન સમય સાથે સરખાવે છે. જ્યારે રીસીવર એક કલાક અટકેલું હોય, ત્યારે એપ્લાયર બેકલોગ પૂરો કરીને જે મળ્યું તેના અંત સુધી પહોંચી શકે છે, અને ત્યારે આંકડો શૂન્ય થઈ જાય છે જોકે રેપ્લિકા સ્રોતથી એક કલાક પાછળ છે. આ માપ એપ્લાયરની કતાર માપે છે, રેપ્લિકાની સમયસરતા નહીં.

તેના બદલે ચલાવેલા વ્યવહારોને સ્રોત પાસે ઉપલબ્ધ હોય તેની સાથે સરખાવો. એ સરખામણી અટકેલા રીસીવરમાં પણ ટકે છે.

પુનઃપ્રાપ્તિની સાચી વિન્ડો રિટેન્શન નક્કી કરે છે

પકડવા માટે જરૂરી છે કે સ્રોત રેપ્લિકાને જોઈતા વ્યવહારો હજી રાખે. તે સાફ થઈ જાય પછી રેપ્લિકા તેમને લાવી શકતું નથી, અને કેટલી પણ પુનઃજોડણી એ બદલતી નથી.

GTID ઓટો-પોઝિશનિંગ સાથે નિષ્ફળતા સ્પષ્ટ છે: રેપ્લિકા એવો ઇતિહાસ માગે છે જે સ્રોત હવે રાખતો નથી અને આગળ વધવાનો ઇનકાર કરે છે. ત્યારે વિકલ્પો છે ગુમ થયેલી ઘટનાઓ હજી ધરાવતા સ્રોત પાસેથી લેવી, અથવા બેકઅપમાંથી ફરી બનાવીને તેને પકડવા દેવું. ખાલી જગ્યા છોડી દેવી એ પકડવું નથી, અને તે એવી રેપ્લિકા છોડે છે જેનો ડેટા ચૂપચાપ અધૂરો છે. અપેક્ષિત કાપની અવધિને સ્રોત પરના બાઈનરી લોગ રિટેન્શન અને ફેરફારના દર સાથે સરખાવીને વિન્ડોનું આયોજન કરો, કારણ કે એ ત્રણ આંકડા નક્કી કરે છે કે કાપ બિલકુલ પુનઃપ્રાપ્ત થઈ શકે છે કે નહીં.

સૂચકનો રંગ નહીં, પકડવું ચકાસો

માર્ગ પુનઃસ્થાપિત કરો, જેમાં નામ-નિરાકરણ અને પરિવહન સુરક્ષાનો સમાવેશ છે, પછી જુઓ કે હાલની ચેનલ પોતાની નીતિ અનુસાર ફરી જોડાય છે કે નહીં. દખલ કરતાં પહેલાં તેને નિશ્ચિત અંતરાલ આપો, અને એ અંતરાલના બંને છેડે પ્રાપ્તિ અને ઉપયોગની પ્રગતિ નોંધો. ફરી શરૂ થતી ચેનલ અને અદ્યતન ચેનલ અલગ તારણો છે.

ખાતરી કરો કે એપ્લાયર સ્રોતની વર્તમાન સ્થિતિ સુધી પહોંચ્યું છે, ફક્ત જૂના બેકલોગના અંત સુધી નહીં. તપાસો કે એપ્લાયરમાં કોઈ ભૂલ રાહ જોતી નથી, કારણ કે એક નિષ્ફળ ઘટના પ્રગતિ અટકાવે છે જ્યારે રીસીવર જોડાયેલું હોવાનું જણાવતું રહે છે. પછી પુરાવા નોંધો: ચેનલનું નામ, બંને તબક્કાની સ્થિતિ, ચલાવેલી સ્થિતિ અને સમય. લીલું સૂચક એક દાવો છે; સ્થિતિ એક હકીકત છે.