Bij Citymobil gebruiken we een MySQL-database als onze belangrijkste permanente gegevensopslag. Wij beschikken over meerdere databaseclusters voor diverse diensten en doeleinden.

De constante beschikbaarheid van de master is een kritische indicator voor de prestaties van het hele systeem en de afzonderlijke onderdelen ervan. Automatisch clusterherstel in het geval van een masterstoring vermindert de responstijd bij incidenten en de systeemuitval aanzienlijk. In dit artikel zal ik kijken naar een ontwerp met hoge beschikbaarheid (HA) voor een MySQL-cluster op basis van MySQL-orkestrator en virtuele IP-adressen (VIP).

HA-oplossing op basis van VIP

Eerst zal ik u kort vertellen wat ons gegevensopslagsysteem is.

We gebruiken een klassiek replicatieschema met één schrijftoegankelijke master en meerdere alleen-lezen replica's. Een cluster kan een tussenliggende master bevatten: een knooppunt dat zowel een replica als een master voor anderen is. Klanten hebben toegang tot replica's via HAProxy, wat een gelijkmatige verdeling van de belasting en eenvoudig schalen mogelijk maakt. Het gebruik van HAProxy heeft historische redenen en we zijn momenteel bezig met de migratie naar ProxySQL.

Replicatie wordt uitgevoerd in semi-synchrone modus op basis van GTID. Dit betekent dat ten minste één replica een transactie moet registreren voordat deze als succesvol wordt beschouwd. Deze replicatiemodus biedt een optimale balans tussen prestaties en gegevensveiligheid in het geval van een masternode-storing. In principe worden alle wijzigingen overgedragen van de master naar de replica's met behulp van Row Based Replication (RBR), maar sommige knooppunten kunnen dat wel hebben mixed binlog format.

De orkestrator werkt periodiek de status van de clustertopologie bij, analyseert de ontvangen informatie en kan bij problemen een automatische herstelprocedure starten. De ontwikkelaar is verantwoordelijk voor de procedure zelf, omdat deze op verschillende manieren kan worden geïmplementeerd: op basis van VIP, DNS, met behulp van service-discovery-services of zelfgeschreven mechanismen.

Een eenvoudige manier om een ​​master te herstellen als deze mislukt, is door zwevende VIP-adressen te gebruiken.

Wat u moet weten over deze oplossing voordat u verder gaat:

• Een VIP is een IP-adres dat niet is gekoppeld aan een specifieke fysieke netwerkinterface. Als een knooppunt uitvalt of tijdens gepland onderhoud, kunnen we de VIP met minimale downtime overzetten naar een andere bron.
• Het vrijgeven en uitgeven van een virtueel IP-adres is een goedkope en snelle operatie.
• Om met VIP te werken, heb je toegang tot de server nodig via SSH of het gebruik van speciale hulpprogramma's, bijvoorbeeld keepalived.

Laten we eens kijken naar mogelijke problemen met onze wizard en ons voorstellen hoe het automatische herstelmechanisme zou moeten werken.

De netwerkverbinding met de master is verdwenen of er is een probleem opgetreden op hardwareniveau en de server is niet beschikbaar

1. De Orchestrator werkt de clustertopologie bij. Elke replica meldt dat de master niet beschikbaar is. De orkestrator start het proces van het selecteren van een replica die geschikt is voor de rol van de nieuwe master en begint met het herstel.
2. We proberen de VIP van de oude meester te verwijderen - zonder succes.
3. De replica schakelt over naar de rol van meester. De topologie wordt opnieuw opgebouwd.
4. Een nieuwe netwerkinterface toevoegen met VIP. Omdat het niet mogelijk was om de VIP te verwijderen, sturen we periodiek op de achtergrond een verzoek gratis ARP. Met dit type verzoek/antwoord kunt u de IP- en MAC-adrestoewijzingstabel op de aangesloten switches bijwerken, waardoor u wordt geïnformeerd dat onze VIP is verhuisd. Hierdoor wordt de waarschijnlijkheid geminimaliseerd split brain bij het terugbrengen van de oude meester.
5. Alle nieuwe verbindingen worden onmiddellijk doorgestuurd naar de nieuwe master. Oude verbindingen mislukken en herhaalde oproepen naar de database worden op applicatieniveau gedaan.

De server werkt in de normale modus, er is een fout opgetreden op DBMS-niveau

Het algoritme is vergelijkbaar met het vorige geval: het bijwerken van de topologie en het starten van het herstelproces. Omdat de server beschikbaar is, hebben we met succes de VIP op de oude master vrijgegeven, overgezet naar de nieuwe en verschillende ARP-verzoeken verzonden. De mogelijke terugkeer van de oude master mag geen invloed hebben op het opnieuw opgebouwde cluster en de werking van de applicatie.

Andere problemen

Falen van replica's of tussenliggende masters leidt niet tot automatische acties en vereist handmatige tussenkomst.

Er wordt altijd tijdelijk een virtuele netwerkinterface toegevoegd, dat wil zeggen dat na het opnieuw opstarten van de server de VIP niet automatisch wordt toegewezen. Elk database-exemplaar start standaard in de modus Alleen-lezen. De Orchestrator schakelt automatisch over naar de nieuwe master om te schrijven en probeert deze te installeren read only op de oude meester. Deze acties zijn gericht op het verkleinen van de kans split brain.

Er kunnen zich problemen voordoen tijdens het herstelproces, die naast de standaard monitoringtools ook via de gebruikersinterface van de Orchestrator moeten worden gemeld. We hebben de REST API uitgebreid door deze functie toe te voegen (PR momenteel in behandeling).

Het algemene diagram van de HA-oplossing wordt hieronder weergegeven.

Een nieuwe meester kiezen

De orkestrator is slim genoeg en probeert te kiezen de meest geschikte replica als nieuwe master volgens de volgende criteria:

• de replica blijft achter bij de meester;
• MySQL-versie van master en replica;
• replicatietype (RBR, SBR of gemengd);
• locatie in dezelfde of verschillende datacenters;
• наличие errant GTID — transacties die op de replica zijn uitgevoerd en niet op de master;
• Er wordt ook rekening gehouden met aangepaste selectieregels.

Niet elke keu is een ideale kandidaat voor een meester. Er kan bijvoorbeeld een replica worden gebruikt om een ​​back-up van gegevens te maken, of de server heeft een zwakkere hardwareconfiguratie. Orchestrator ondersteunt de handmatige regels waarmee u uw kandidaatselectievoorkeuren kunt aanpassen van meest geprefereerd tot genegeerd.

Reactie- en hersteltijd

In het geval van een incident is het belangrijk om de downtime van het systeem te minimaliseren, dus laten we eens kijken naar de MySQL-parameters die van invloed zijn op het maken en bijwerken van de clustertopologie door de orkestrator:

• slave_net_timeout — het aantal seconden waarin de replica wacht op nieuwe gegevens of een hartslagsignaal van de master voordat de verbinding als verbroken wordt herkend en opnieuw wordt verbonden. Hoe lager de waarde, hoe sneller de replica kan vaststellen dat de communicatie met de master is verbroken. We stellen deze waarde in op 5 seconden.
• MASTER_CONNECT_RETRY — aantal seconden tussen herverbindingspogingen. In het geval van netwerkproblemen zorgt een lage waarde voor deze parameter ervoor dat er snel opnieuw verbinding kan worden gemaakt en wordt voorkomen dat het clusterherstelproces wordt gestart. De aanbevolen waarde is 1 seconde.
• MASTER_RETRY_COUNT — maximum aantal herverbindingspogingen.
• MASTER_HEARTBEAT_PERIOD — interval in seconden waarna de master een hartslagsignaal verzendt. Standaard ingesteld op de helft van de waarde slave_net_timeout.

Orchestrator-parameters:

• DelayMasterPromotionIfSQLThreadNotUpToDate - indien gelijk true, dan wordt de masterrol pas toegepast op de kandidaatreplica als de SQL-thread van de replica alle niet-toegepaste transacties uit het relaylogboek heeft voltooid. We gebruiken deze optie om te voorkomen dat er transacties verloren gaan wanneer alle kandidaat-replica's achterop raken.
• InstancePollSeconds — frequentie van het bouwen en bijwerken van de topologie.
• RecoveryPollSeconds — frequentie van topologieanalyse. Als er een probleem wordt gedetecteerd, wordt topologieherstel gestart. Dit constante, gelijk aan 1 seconde.

Elk clusterknooppunt wordt één keer per keer door de orkestrator ondervraagd InstancePollSeconds seconden Wanneer een probleem wordt gedetecteerd, wordt de clusterstatus geforceerd bijgewerkten vervolgens wordt de uiteindelijke beslissing genomen om herstel uit te voeren. Door te experimenteren met verschillende database- en orkestratorparameters konden we de respons- en hersteltijd terugbrengen tot 30 seconden.

Testbank

We zijn begonnen met het testen van het HA-schema met de ontwikkeling van een lokaal testbank en verdere implementatie in test- en productieomgevingen. De lokale stand is volledig geautomatiseerd op basis van Docker en biedt de mogelijkheid om te experimenteren met de configuratie van de Orchestrator en het netwerk, het cluster op te schalen van 2-3 servers naar enkele tientallen en oefeningen uit te voeren in een veilige omgeving.

Tijdens de oefeningen kiezen we een van de probleememulatiemethoden: schiet direct op de meester met behulp van kill -9, beëindig het proces zachtjes en stop de server (docker-compose stop), simuleer netwerkproblemen met behulp van iptables -j REJECT of iptables -j DROP. Wij verwachten de volgende resultaten:

• de orkestrator zal problemen met de master detecteren en de topologie in maximaal 10 seconden bijwerken;
• de herstelprocedure start automatisch: de netwerkconfiguratie verandert, de rol van de master gaat over naar de replica, de topologie wordt opnieuw opgebouwd;
• de nieuwe master zal beschrijfbaar worden, live replica's zullen niet verloren gaan tijdens het herbouwproces;
• gegevens zullen naar de nieuwe master worden geschreven en gerepliceerd;
• De totale hersteltijd bedraagt ​​niet meer dan 30 seconden.

Zoals u weet, kan het systeem zich anders gedragen in test- en productieomgevingen als gevolg van verschillende hardware- en netwerkconfiguraties, verschillen in synthetische en werkelijke belasting, enz. Daarom voeren we periodiek oefeningen uit in reële omstandigheden, waarbij we controleren hoe het systeem zich gedraagt ​​wanneer de netwerkconnectiviteit verloren gaat of de afzonderlijke onderdelen ervan verslechteren. In de toekomst willen we voor beide omgevingen een volledig identieke infrastructuur bouwen en het testen ervan automatiseren.

Bevindingen

De gezondheid van het hoofdopslagsysteemknooppunt is een van de hoofdtaken van het SRE- en operationele team. Dankzij de implementatie van de Orchestrator- en HA-oplossing op basis van VIP hebben we de volgende resultaten kunnen bereiken:

• betrouwbare detectie van problemen met de topologie van het databasecluster;
• automatische en snelle reactie op mastergerelateerde incidenten, waardoor de systeemuitval wordt verminderd.

De oplossing heeft echter zijn beperkingen en nadelen:

• Voor het opschalen van het HA-schema naar verschillende datacenters is één enkel L2-netwerk tussen deze datacentra nodig;
• Voordat we VIP toewijzen aan de nieuwe master, moeten we deze vrijgeven aan de oude. Het proces is opeenvolgend, wat de hersteltijd verlengt;
• Voor het vrijgeven van de VIP is SSH-toegang tot de server vereist, of een andere methode om procedures op afstand aan te roepen. Omdat de server of database problemen ondervindt die het herstelproces hebben veroorzaakt, kunnen we er niet zeker van zijn dat de VIP-verwijdering succesvol zal worden voltooid. En dit kan leiden tot het verschijnen van twee servers met hetzelfde virtuele IP-adres en een probleem split brain.

Vermijden split brain, kunt u de methode gebruiken STONITH ("Shoot The Other Node In The Head"), waardoor het probleemknooppunt volledig wordt geïsoleerd of uitgeschakeld. Er zijn andere manieren om cluster hoge beschikbaarheid te implementeren: een combinatie van VIP en DNS, service-discovery en proxy-services, synchrone replicatie en andere methoden die hun eigen voor- en nadelen hebben.

Ik heb gesproken over onze aanpak voor het maken van een MySQL failovercluster. Het is eenvoudig te implementeren en biedt onder de huidige omstandigheden een acceptabel betrouwbaarheidsniveau. Naarmate het hele systeem in het algemeen en de infrastructuur in het bijzonder zich ontwikkelen, zal deze aanpak ongetwijfeld evolueren.

Bron: www.habr.com