Reslave di un server master MySQL bloccato in configurazione di replica semisincrona

In una configurazione master-slave MySQL 5.7 che utilizza l'impostazione di replica semisincrona predefinita per rpl_semi_sync_master_wait_point , un arresto anomalo del master e il failover sullo slave sono considerati senza perdite. Tuttavia, quando il master in crash ritorna, potresti scoprire che ha transazioni che non sono presenti nel master corrente (che in precedenza era uno slave). Questo comportamento può essere sconcertante, dato che la replica semisincrona dovrebbe essere senza perdite, ma in realtà si tratta di un comportamento previsto in MySQL. Perché esattamente questo accade è spiegato in dettaglio nel post del blog di Jean-François Gagné (JF).

Dato uno scenario del genere, la documentazione di MySQL consiglia di eliminare il master in crash e di non riavviarlo. Tuttavia, scartare un server come questo è costoso e inefficiente. In questo post del blog, spiegheremo un approccio per rilevare e correggere le transazioni sul server master MySQL in crash in una configurazione di replica semisincrona e come riattivarlo nella configurazione master-slave.

Perché è importante rilevare transazioni extra sul master recuperato?

Le transazioni extra sul master recuperato possono manifestarsi in due modi:

1. La replica di MySQL non riesce quando il master recuperato viene riattivato

In genere, questo accade quando hai una chiave primaria con incremento automatico. Quando il nuovo master MySQL inserisce una riga in una tabella di questo tipo, la replica avrà esito negativo perché la chiave esiste già sullo slave.

Un altro scenario è quando l'app riprova la transazione non riuscita durante l'arresto anomalo principale. Sul master MySQL recuperato (che ora è uno slave), questa transazione esisterebbe effettivamente e, di nuovo, risulterebbe in un errore di replica.

In genere, l'errore di replica di MySQL sarebbe simile a questo:

2. Incoerenza silenziosa nei dati tra il nuovo master MySQL e lo slave (master recuperato)

Nei casi in cui l'applicazione non riprova la transazione non riuscita e non si verificano collisioni di chiavi primarie in futuro, potrebbe non verificarsi un errore di replica. Di conseguenza, l'incoerenza dei dati potrebbe non essere rilevata.

In entrambi i casi precedenti, l'elevata disponibilità o l'integrità dei dati della configurazione di MySQL è influenzata, motivo per cui è così importante rilevare questa condizione il prima possibile.

Come rilevare transazioni extra sul MySQL Master recuperato

Possiamo rilevare se ci sono transazioni extra sul master recuperato usando la funzione MySQL GTID (identificatore di transazione globale):

GTID_SUBSET(set1 ,set2 ):dati due set di ID transazione globali set1 e set2 , restituisce true se tutti i GTID in set1 sono anche in set2 . Restituisce false altrimenti.

Usiamo un esempio per capirlo.

• GTID impostato sul master recuperato il cui UUID è:'54a63bc3-d01d-11e7-bf52-000d3af93e52 ' è:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
• Il set GTID del nuovo master il cui UUID è:'57956099-d01d-11e7-80bc-000d3af97c09 ' è:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'

Ora, se chiamiamo la funzione GTID_SUBSET come GTID_SUBSET(set GTID del master recuperato, set GTID del nuovo master) , il valore restituito sarà vero, solo se il master recuperato non ha transazioni extra. Nel nostro esempio sopra, poiché il master recuperato ha transazioni extra da 9691 a 9700, il risultato della query precedente è falso.

Come rendere nuovamente schiavo il MySQL Master recuperato che ha transazioni extra

In base al passaggio precedente, è possibile sapere se il master recuperato ha transazioni extra e quali transazioni stanno utilizzando la funzione GTID:GTID_SUBTRACT(GTID set of master recuperato, set GTID del nuovo master).

È anche possibile estrarre queste transazioni extra dai log binari e salvarle. Potrebbe essere utile per il tuo team aziendale rivedere in seguito queste transazioni per assicurarsi che non stiamo perdendo inavvertitamente informazioni aziendali importanti, anche se non erano impegnate. Una volta fatto ciò, abbiamo bisogno di un modo per sbarazzarci di queste transazioni extra in modo che il master recuperato possa essere riattivato senza problemi.

Uno dei modi più semplici per farlo è acquisire un'istantanea di backup sul master corrente e ripristinare i dati sullo slave corrente. Ricorda che devi conservare l'UUID di questo server come prima. Dopo aver ripristinato i dati, il server può essere riattivato e inizierà la replica dal punto dello snapshot ripristinato. Presto avrai di nuovo uno schiavo in salute!

I passaggi precedenti sono molto noiosi se devi eseguirli manualmente, ma il servizio di hosting MySQL completamente gestito di ScaleGrid può automatizzare l'intero processo per te senza alcun intervento richiesto. Ecco come funziona:

Se il master attuale si arresta in modo anomalo, ScaleGrid automatizza il processo di failover e promuove uno slave adatto come nuovo master. Il vecchio master viene quindi recuperato e rileviamo automaticamente se ci sono transazioni extra su di esso. Se ne vengono trovati, l'implementazione di MySQL viene messa in uno stato degradato e utilizziamo strumenti automatizzati per estrarre e salvare le transazioni extra per la tua revisione. Il nostro team di supporto può quindi ripristinare il vecchio master a un buono stato e riattivarlo nella configurazione master-slave in modo da avere una distribuzione sana!

Vuoi provarlo? Inizia una prova gratuita di 30 giorni per esplorare tutte le funzionalità di gestione del database MySQL su ScaleGrid.