Bei Citymobil benotze mir eng MySQL Datebank als eis Haaptpersistent Datelagerung. Mir hunn e puer Datebankclustere fir verschidde Servicer an Zwecker.

D'konstante Disponibilitéit vum Master ass e kriteschen Indikator fir d'Leeschtung vum ganze System a sengen eenzelnen Deeler. Automatesch Stärekoup Erhuelung am Fall vun engem Meeschter Echec reduzéiert vill Tëschefall Äntwert Zäit a System Auswee. An dësem Artikel wäert ech eng héich Disponibilitéit (HA) Design fir e MySQL Stärekoup baséiert op MySQL Orchestrator a virtuell IP Adressen (VIP).

HA Léisung baséiert op VIP

Als éischt wäert ech Iech kuerz soen wat eisen Datelagerungssystem ass.

Mir benotzen e klassesche Replikatiounsschema mat engem schreiwen-zougängleche Master a multiple read-only replicas. E Stärekoup kann en Zwëschenmeeschter enthalen - e Knuet dee souwuel eng Replica wéi och e Master fir anerer ass. Clienten Zougang zu Repliken duerch HAProxy, wat e souguer Laaschtverdeelung an einfach Skala erlaabt. D'Benotzung vun HAProxy ass wéinst historesche Grënn, a mir sinn am Moment am Prozess vun der Migratioun op ProxySQL.

Replikatioun gëtt am semi-synchrone Modus duerchgefouert baséiert op GTID. Dëst bedeit datt op d'mannst eng Replik eng Transaktioun aloggen muss ier se als erfollegräich ugesi gëtt. Dëse Replikatiounsmodus bitt en optimalen Gläichgewiicht tëscht Leeschtung an Datesécherheet am Fall vun engem Master Node Echec. Prinzipiell ginn all Ännerunge vum Master op d'Replikaen transferéiert Row Based Replication (RBR), awer e puer Node kënnen hunn mixed binlog format.

Den Orchestrator aktualiséiert periodesch den Zoustand vun der Clustertopologie, analyséiert d'Informatioun, déi kritt gëtt, a wa Probleemer entstinn, kann en eng automatesch Erhuelungsprozedur starten. Den Entwéckler ass verantwortlech fir d'Prozedur selwer, well se op verschidde Manéieren ëmgesat ka ginn: baséiert op VIP, DNS, mat Service Entdeckungsservicer oder selbstgeschriwwe Mechanismen.

Een einfache Wee fir e Meeschter ze restauréieren wann et net geet ass schwiewend VIP Adressen ze benotzen.

Wat Dir iwwer dës Léisung wësse musst ier Dir weider geet:

• E VIP ass eng IP Adress déi net mat enger spezifescher kierperlecher Netzwierkinterface assoziéiert ass. Wann e Node klappt oder während geplangten Ënnerhalt, kënne mir de VIP op eng aner Ressource mat minimalem Ënnerhalt wiesselen.
• Eng virtuell IP Adress befreien an erausginn ass eng bëlleg a séier Operatioun.
• Fir mat VIP ze schaffen, braucht Dir Zougang zum Server iwwer SSH, oder d'Benotzung vu speziellen Utilities, zum Beispill, keepalived.

Loosst eis op méiglech Probleemer mat eisem Wizard kucken a virstellen wéi den automateschen Erhuelungsmechanismus funktionnéiert.

D'Netzverbindung mam Master ass verschwonnen, oder e Problem ass op Hardwareniveau entstanen, an de Server ass net verfügbar

1. Den Orchestrator aktualiséiert d'Clustertopologie, all Replik bericht datt de Master net verfügbar ass. Den Orchester fänkt de Prozess un fir eng Replika ze wielen déi gëeegent ass fir d'Roll vum neie Meeschter a fänkt d'Erhuelung un.
2. Mir probéieren de VIP vum ale Meeschter ze läschen - ouni Erfolleg.
3. D'Replique wiesselt op d'Roll vum Meeschter. D'Topologie gëtt nei opgebaut.
4. Füügt en neit Netzwierk Interface mat VIP. Well et net méiglech war de VIP ze läschen, fänken mir periodesch eng Ufro am Hannergrond ze schécken gratis ARP. Dës Zort vun Ufro / Äntwert erlaabt Iech d'IP- an MAC-Adress-Mapping-Table op de verbonne Schalter ze aktualiséieren, an domat Iech matdeelen datt eise VIP geplënnert ass. Dëst miniméiert d'Wahrscheinlechkeet split brain beim Retour vum ale Meeschter.
5. All nei Verbindunge ginn direkt op den neie Master ëmgeleet. Al Verbindungen feelen a widderholl Uruff un d'Datebank ginn um Applikatiounsniveau gemaach.

De Server funktionnéiert am normale Modus, e Feeler ass um DBMS Niveau geschitt

Den Algorithmus ass ähnlech wéi de fréiere Fall: d'Topologie aktualiséieren an den Erhuelungsprozess starten. Well de Server verfügbar ass, verëffentlechen mir de VIP erfollegräich op den alen Meeschter, transferéieren se op den neien a schécken e puer ARP Ufroen. De méigleche Retour vum alen Meeschter sollt net den opgebaute Cluster an d'Operatioun vun der Applikatioun beaflossen.

Aner Probleemer

Echec vun Repliken oder Mëttelstuf Meeschter féiert net op automatesch Aktiounen a verlaangt manuell Interventioun.

Eng virtuell Netzwierk-Interface gëtt ëmmer temporär bäigefüügt, dat heescht, no engem Server-Reboot gëtt de VIP net automatesch zougewisen. All Datebank Instanz fänkt am Read-only Modus als Standard un, den Orchester wiesselt automatesch den neie Master fir ze schreiwen a probéiert ze installéieren read only op den ale Meeschter. Dës Aktiounen zielen d'Wahrscheinlechkeet ze reduzéieren split brain.

Probleemer kënne während dem Erhuelungsprozess entstoen, wat och duerch d'Orchestrator UI zousätzlech zu Standard Iwwerwachungsinstrumenter matgedeelt gëtt. Mir hunn de REST API erweidert andeems dës Feature bäigefüügt (PR momentan iwwerpréift).

Den allgemenge Diagramm vun der HA Léisung gëtt hei ënnen presentéiert.

Wiel vun engem neie Meeschter

Den Orchester ass intelligent genuch a probéiert ze wielen déi gëeegent Replica als neie Meeschter no de folgende Critèren:

• der Replica lags hannert de Meeschter;
• MySQL Versioun vum Master a Replik;
• Replikatiounstyp (RBR, SBR oder gemëscht);
• Plaz an der selwechter oder verschidden Daten Zentren;
• Disponibilitéit errant GTID - Transaktiounen déi op der Replica ausgefouert goufen an net um Master sinn;
• Benotzerdefinéiert Auswiel Regelen sinn och Rechnung gedroe.

Net all Cue ass en ideale Kandidat fir e Master. Zum Beispill kann eng Replika benotzt ginn fir Daten ze backen, oder de Server huet eng méi schwaach Hardwarekonfiguratioun. Orchester ënnerstëtzt manuell Reegelen mat deenen Dir Är Kandidatenauswiel Virléiften personaliséiere kënnt vu meescht bevorzugt bis ignoréiert.

Äntwert an Erhuelung Zäit

Am Fall vun engem Tëschefall ass et wichteg d'Systemdowntime ze minimiséieren, also loosst eis d'MySQL-Parameteren betruechten, déi d'Schafung an d'Aktualiséierung vun der Clustertopologie vum Orchestrator beaflossen:

• slave_net_timeout - d'Zuel vun de Sekonnen, während deenen d'Replika op nei Donnéeën oder en Häerzschlag-Signal waart fir vum Master z'erreechen, ier d'Verbindung als verluer an erëm ugeschloss gëtt. Wat de Wäert méi niddereg ass, dest méi séier kann d'Replique feststellen datt d'Kommunikatioun mam Master gebrach ass. Mir setzen dëse Wäert op 5 Sekonnen.
• MASTER_CONNECT_RETRY - Zuel vu Sekonnen tëscht Reconnection Versich. Am Fall vun Netzproblemer, wäert e nidderegen Wäert fir dëse Parameter eng séier Reconnectioun erlaben a verhënneren datt de Cluster Erhuelungsprozess ufänkt. De recommandéierte Wäert ass 1 Sekonn.
• MASTER_RETRY_COUNT - maximal Unzuel vun Reconnection Versich.
• MASTER_HEARTBEAT_PERIOD - Intervall a Sekonnen, no deem de Master en Häerzschlagsignal schéckt. Standard op d'Halschent vum Wäert slave_net_timeout.

Orchestrator Parameteren:

• DelayMasterPromotionIfSQLThreadNotUpToDate - wann gläich true, da gëtt d'Meeschterroll net op d'Kandidatreplique applizéiert bis de SQL-Thread vun der Replika all net applizéiert Transaktioune vum Relais-Log ofgeschloss huet. Mir benotzen dës Optioun fir Verléierer Transaktiounen ze vermeiden wann all Kandidatetitelen hannertenee falen.
• InstancePollSeconds - Frequenz vum Bau an Aktualiséierung vun der Topologie.
• RecoveryPollSeconds - Frequenz vun Topologie Analyse. Wann e Problem festgestallt gëtt, gëtt d'Topologie Erhuelung initiéiert. Dëst konstant, gläich wéi 1 Sekonn.

All Cluster Node gëtt eemol all vum Orchester gepollt InstancePollSeconds Sekonnen Wann e Problem festgestallt gëtt, gëtt de Clusterzoustand gezwongen aktualiséiert, an dann ass déi definitiv Entscheedung fir d'Erhuelung ze maachen. Duerch Experimentéiere mat verschiddene Datebank- an Orchesterparameter konnte mir d'Äntwert an d'Erhuelungszäit op 30 Sekonnen reduzéieren.

Teststand

Mir hunn ugefaang den HA Schema ze testen mat der Entwécklung vun engem lokalen Testbänk a weider Ëmsetzung an Test- a Produktiounsëmfeld. De lokale Stand ass voll automatiséiert baséiert op Docker an erlaabt Iech mat der Konfiguratioun vum Orchester an dem Netz ze experimentéieren, de Cluster vun 2-3 Serveren op e puer Dutzend ze skaléieren an Übungen an engem sécheren Ëmfeld ze maachen.

Wärend den Übungen wielt mir ee vun de Problem-Emuléierungsmethoden: Schéisst direkt de Master mat kill -9, mëll de Prozess ofzeschléissen an de Server stoppen (docker-compose stop), simuléiert Netzwierkproblemer benotzt iptables -j REJECT oder iptables -j DROP. Mir erwaarden déi folgend Resultater:

• den Orchester wäert Problemer mam Meeschter entdecken an d'Topologie an net méi wéi 10 Sekonnen aktualiséieren;
• d'Erhuelungsprozedur fänkt automatesch un: d'Netzkonfiguratioun ännert sech, d'Roll vum Meeschter gëtt op d'Replique passéiert, d'Topologie gëtt nei opgebaut;
• den neie Meeschter gëtt schrëftlech, Live Repliken ginn net während dem Opbauprozess verluer;
• Daten fänken un den neie Meeschter ze schreiwen a replizéiert ze ginn;
• Déi total Erhuelungszäit wäert net méi wéi 30 Sekonnen sinn.

Wéi Dir wësst, kann de System anescht an Test- a Produktiounsëmfeld behuelen wéinst verschiddenen Hardware- an Netzkonfiguratiounen, Differenzen an der synthetescher a reeller Belaaschtung, etc. Dofir maache mir periodesch Übungen an echte Konditiounen, iwwerpréift wéi de System sech behält wann d'Netzverbindung verluer ass oder seng eenzel Deeler ofgebaut ginn. An Zukunft wëlle mir eng komplett identesch Infrastruktur fir béid Ëmfeld bauen an hir Tester automatiséieren.

Conclusiounen

D'Gesondheet vum Haaptspeichersystem Node ass eng vun den Haaptaufgaben vum SRE an Operatiounsteam. D'Ëmsetzung vun der Orchester an HA Léisung baséiert op VIP erlaabt eis déi folgend Resultater z'erreechen:

• zouverlässeg Detektioun vu Problemer mat der Topologie vum Datebankcluster;
• automatesch a séier Äntwert op Meeschtesch-Zesummenhang Tëschefäll, reduzéieren System Auswee.

Wéi och ëmmer, d'Léisung huet seng Aschränkungen an Nodeeler:

• d'Skaléierung vum HA Schema op verschidde Rechenzentren erfuerdert en eenzegt L2 Netzwierk tëscht hinnen;
• Ier Dir VIP op den neie Meeschter zougewisen, musse mir et op der aler fräiginn. De Prozess ass sequenziell, wat d'Erhuelungszäit vergréissert;
• d'Verëffentlechung vum VIP erfuerdert SSH Zougang zum Server, oder all aner Method fir Remote Prozeduren ze ruffen. Well de Server oder d'Datebank Problemer huet, déi den Erhuelungsprozess verursaacht hunn, kënne mir net sécher sinn datt d'VIP-Entfernung erfollegräich ofgeschloss ass. An dëst kann zu der Erscheinung vun zwee Server mat der selwechter virtueller IP Adress an e Problem féieren split brain.

Ze vermeiden split brain, Dir kënnt d'Method benotzen STONITH ("Shoot The Other Node In The Head"), wat de Problemknuet komplett isoléiert oder deaktivéiert. Et ginn aner Weeër fir Cluster High Disponibilitéit ëmzesetzen: eng Kombinatioun vu VIP an DNS, Service Entdeckung a Proxy Servicer, Synchron Replikatioun an aner Methoden déi hir eegen Nodeeler a Virdeeler hunn.

Ech hunn iwwer eis Approche geschwat fir e MySQL Failover Cluster ze kreéieren. Et ass einfach ze implementéieren a bitt en akzeptablen Niveau vun Zouverlässegkeet ënner aktuellen Konditiounen. Wéi de ganze System am Allgemengen an d'Infrastruktur besonnesch entwéckelen, wäert dës Approche sech ouni Zweifel entwéckelen.

Source: will.com