Replicació de MySQL després d’una caiguda de VPN: llegiu primer les dues etapes
Un camí interromput no són transaccions perdudes. Llegiu el receptor i l’aplicador per separat i després comproveu què conserva encara l’origen.
El monitoratge de la replicació es torna vermell quan cau la VPN, i l’instint és reiniciar una posició. Aquest instint és com una interrupció de xarxa es converteix en un problema de dades. Un camí caigut no diu res sobre què ha rebut o aplicat la rèplica, i aquestes són dues etapes amb dos estats. Llegiu-les per separat abans de canviar res.
Dues etapes, dues respostes separades
Una rèplica asíncrona convencional fa dues feines. El receptor es connecta a l’origen, extreu esdeveniments i els escriu al registre de relé localment. L’aplicador llegeix aquest registre de relé i executa els esdeveniments contra la rèplica. Quan el camí es trenca, el receptor s’atura immediatament mentre l’aplicador continua treballant el retard que ja hi ha al disc. Per tant, una interrupció produeix dues preguntes diferents: ha tornat la connexió i s’ha aplicat la feina acumulada? Tractar-les com una sola pregunta barreja dos estats en una resposta enganyosa.
Que el receptor es recuperi us diu que el camí funciona. No diu res sobre com de endarrerit va l’aplicador ni si va trobar un error mentre estava desconnectat.
Llegiu el canal amb l’ordre correcta
A MySQL 8.4, SHOW REPLICA STATUS retorna una fila per canal configurat, així que llegiu la fila del canal que voleu i no la primera de la llista. Replica_IO_Running separa un receptor connectat d’un que s’està connectant o està aturat, i Replica_SQL_Running descriu l’aplicador. Llegiu les columnes d’error al costat, perquè un receptor que es reconnecta i falla immediatament deixa un missatge que cap indicador d’estat mostrarà. Les versions antigues fan servir noms de columna diferents, així que no traduïu una recepta antiga només reanomenant les ordres.
Comproveu també la identitat de l’origen i els filtres configurats. Una rèplica apuntada a l’origen equivocat, o filtrada més estretament del que penseu, informa de salut mentre replica una cosa diferent de la que espereu.
Per què un zero de retard pot mentir
El valor de retard compara la marca de temps de l’últim esdeveniment aplicat amb l’hora actual. Quan el receptor ha estat aturat una hora, l’aplicador pot treballar el retard i arribar al final del que ha rebut, i llavors el número cau a zero tot i que la rèplica va una hora endarrerida respecte de l’origen. La mètrica mesura la cua de l’aplicador, no l’actualitat de la rèplica.
Compareu en canvi les transaccions executades amb el que l’origen té disponible. Aquesta comparació sobreviu a un receptor encallat.
La retenció fixa la finestra real de recuperació
Posar-se al dia requereix que l’origen encara guardi les transaccions que la rèplica necessita. Un cop purgades, la rèplica no les pot obtenir, i cap quantitat de reconnexions ho canvia.
Amb l’autoposicionament GTID la fallada és explícita: la rèplica demana un historial que l’origen ja no guarda i es nega a continuar. Llavors les opcions són obtenir els esdeveniments que falten d’un origen que encara els té, o reconstruir des d’una còpia de seguretat i deixar que s’hi posi al dia. Saltar-se el buit no és posar-se al dia, i deixa una rèplica amb dades silenciosament incompletes. Planifiqueu la finestra comparant la durada esperada de la interrupció amb la retenció del registre binari a l’origen i el ritme de canvi, perquè aquests tres números decideixen si la interrupció és recuperable.
Verifiqueu la posada al dia, no el color d’un indicador
Restaureu el camí, incloent-hi la resolució de noms i la seguretat del transport, i després observeu si el canal existent es reconnecta segons la seva pròpia política. Doneu-li un interval definit abans d’intervenir i registreu el progrés de recepció i aplicació als dos extrems d’aquest interval. Un canal que es reinicia i un canal que està al dia són troballes diferents.
Confirmeu que l’aplicador ha arribat a la posició actual de l’origen, no només al final del retard antic. Comproveu que no hi espera cap error a l’aplicador, perquè un esdeveniment fallit atura el progrés mentre el receptor continua informant que està connectat. Després registreu l’evidència: nom del canal, tots dos estats d’etapa, la posició executada i l’hora. Un indicador verd és una afirmació; la posició és un fet.