Re-Slaven van een gecrashte MySQL-masterserver in semisynchrone replicatieconfiguratie

In een MySQL 5.7 master-slave-configuratie die de standaard semi-synchrone replicatie-instelling gebruikt voor rpl_semi_sync_master_wait_point , wordt een crash van de master en een failover naar de slave als verliesvrij beschouwd. Wanneer de gecrashte master echter terugkomt, kan het zijn dat deze transacties heeft die niet aanwezig zijn in de huidige master (die voorheen een slave was). Dit gedrag kan raadselachtig zijn, aangezien semi-synchrone replicatie geacht wordt verliesvrij te zijn, maar dit is eigenlijk een verwacht gedrag in MySQL. Waarom dit precies gebeurt, wordt uitgebreid uitgelegd in de blogpost van Jean-François Gagné (JF).

Gezien een dergelijk scenario raadt MySQL-documentatie aan om de gecrashte master te verwijderen en niet opnieuw te starten. Het weggooien van een server als deze is echter duur en inefficiënt. In deze blogpost leggen we een aanpak uit om transacties op de gecrashte MySQL-masterserver te detecteren en op te lossen in een semisynchrone replicatieconfiguratie, en hoe u deze opnieuw kunt slaven in uw master-slave-configuratie.

Waarom is het belangrijk om extra transacties op de herstelde master te detecteren?

De extra transacties op de herstelde master kunnen zich op twee manieren manifesteren:

1. MySQL-replicatie mislukt wanneer de herstelde master opnieuw tot slaaf wordt gemaakt

Dit gebeurt meestal wanneer je een primaire sleutel voor automatisch verhogen hebt. Wanneer de nieuwe MySQL-master een rij in zo'n tabel invoegt, zal de replicatie mislukken omdat de sleutel al op de slave bestaat.

Een ander scenario is wanneer uw app de transactie opnieuw probeert die was mislukt tijdens de mastercrash. Op de herstelde MySQL-master (die nu een slaaf is), zou deze transactie daadwerkelijk bestaan, en opnieuw resulteert dit in een replicatiefout.

Normaal gesproken ziet de MySQL-replicatiefout er als volgt uit:

2. Stille inconsistentie in gegevens tussen de nieuwe MySQL-master en slave (herstelde master)

In gevallen waarin de toepassing de mislukte transactie niet opnieuw probeert en er in de toekomst geen botsingen met de primaire sleutel zijn, treedt mogelijk geen replicatiefout op. Als gevolg hiervan kan de inconsistentie van de gegevens onopgemerkt blijven.

In beide bovenstaande gevallen wordt ofwel de hoge beschikbaarheid ofwel de gegevensintegriteit van uw MySQL-configuratie beïnvloed. Daarom is het zo belangrijk om deze toestand zo vroeg mogelijk te detecteren.

Extra transacties op de herstelde MySQL-master detecteren

We kunnen detecteren of er extra transacties zijn op de herstelde master met behulp van de MySQL GTID-functie (global transaction identifier):

GTID_SUBSET(set1 ,set2 ):Gegeven twee sets globale transactie-ID's set1 en set2 , retourneert true als alle GTID's in set1 zitten ook in set2 . Retourneert anders false.

Laten we een voorbeeld gebruiken om dit te begrijpen.

• GTID ingesteld op de herstelde master waarvan de UUID is:'54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ is:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
• De GTID-set van de nieuwe master waarvan de UUID is:'57956099-d01d-11e7-80bc-000d3af97c09 ’ is:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'

Als we nu de GTID_SUBSET-functie aanroepen als GTID_SUBSET(GTID-set van herstelde master, GTID-set van nieuwe master) , zal de geretourneerde waarde waar zijn, alleen als de herstelde master geen extra transacties heeft. In ons voorbeeld hierboven, aangezien de herstelde master extra transacties 9691 tot 9700 heeft, is het resultaat van de bovenstaande zoekopdracht onwaar.

De herstelde MySQL-master die extra transacties heeft opnieuw tot slaaf maken

Op basis van de bovenstaande stap is het mogelijk om te weten of de herstelde master extra transacties heeft en wat deze transacties zijn met behulp van de GTID-functie:GTID_SUBTRACT(GTID-set van herstelde master, GTID-set van nieuwe master).

Het is ook mogelijk om deze extra transacties uit de binaire logs te halen en op te slaan. Het kan nuttig zijn voor uw zakelijke team om deze transacties later te beoordelen om er zeker van te zijn dat we niet per ongeluk belangrijke zakelijke informatie verliezen, ook al was deze niet vastgelegd. Zodra dit is gebeurd, hebben we een manier nodig om van deze extra transacties af te komen, zodat de herstelde master zonder problemen opnieuw tot slaaf kan worden gemaakt.

Een van de eenvoudigste manieren om dit te doen, is door een back-up-snapshot te maken op de huidige master en de gegevens op uw huidige slave te herstellen. Onthoud dat u de UUID van deze server moet behouden zoals voorheen. Nadat u de gegevens hebt hersteld, kan de server opnieuw tot slaaf worden gemaakt en begint de replicatie vanaf het punt van de herstelde momentopname. Binnenkort heb je weer een gezonde slaaf aan het rennen!

De bovenstaande stappen zijn erg vervelend als u ze handmatig moet uitvoeren, maar de volledig beheerde MySQL-hostingservice van ScaleGrid kan het hele proces voor u automatiseren zonder enige tussenkomst. Zo werkt het:

Als je huidige master crasht, automatiseert ScaleGrid het failover-proces en promoot een geschikte slave als de nieuwe master. De oude master wordt dan teruggevonden, en we detecteren automatisch of er extra transacties op staan. Als er een wordt gevonden, wordt de MySQL-implementatie in een verslechterde staat gebracht en gebruiken we geautomatiseerde tools om de extra transacties te extraheren en op te slaan voor uw beoordeling. Ons ondersteuningsteam kan vervolgens de oude master in een goede staat herstellen en deze opnieuw in uw master-slave-configuratie zetten, zodat u een gezonde implementatie zult hebben!

Wil je het eens proberen? Start een gratis proefperiode van 30 dagen om alle MySQL-databasebeheermogelijkheden bij ScaleGrid te verkennen.