Geautomatiseerde failover is vrijwel een must voor veel toepassingen - uptime wordt als vanzelfsprekend beschouwd. Het is best moeilijk te accepteren dat een applicatie 20 of 30 minuten niet beschikbaar is, omdat iemand moet worden opgeroepen om in te loggen en de situatie te onderzoeken voordat er actie wordt ondernomen.
In de echte wereld hebben replicatie-instellingen de neiging om in de loop van de tijd complex en soms rommelig te worden. En er zijn beperkingen. Niet elk knooppunt in een opstelling is bijvoorbeeld een goede masterkandidaat. Misschien verschilt de hardware en hebben sommige replica's minder krachtige hardware omdat ze zijn bedoeld voor bepaalde specifieke soorten werklast? Misschien zit u midden in de migratie naar een nieuwe MySQL-versie en zijn sommige slaven al geüpgraded? Je hebt liever geen master in een recentere versie die repliceert naar oude replica's, omdat dit de replicatie kan verbreken. Als u twee datacenters heeft, één actief en één voor noodherstel, kiest u wellicht liever alleen masterkandidaten in het actieve datacenter, om de master dicht bij de applicatiehosts te houden. Dit zijn slechts voorbeeldsituaties waarin u mogelijk handmatig moet worden ingegrepen tijdens het failoverproces. Gelukkig hebben veel failover-tools een optie om de controle over het proces over te nemen door gebruik te maken van witte lijsten en zwarte lijsten. In deze blogpost willen we u enkele voorbeelden laten zien hoe u het algoritme van ClusterControl voor het selecteren van masterkandidaten kunt beïnvloeden.
Witte lijst en zwarte lijst configuratie
ClusterControl geeft u de mogelijkheid om zowel de witte lijst als de zwarte lijst van replica's te definiëren. Een whitelist is een lijst met replica's die bedoeld zijn om masterkandidaten te worden. Als geen van deze beschikbaar is (ofwel omdat ze niet beschikbaar zijn, of omdat er foutieve transacties zijn, of als er andere obstakels zijn die verhinderen dat een van hen wordt gepromoot), wordt er geen failover uitgevoerd. Op deze manier kunt u bepalen welke hosts beschikbaar zijn om een masterkandidaat te worden. Zwarte lijsten daarentegen bepalen welke replica's niet geschikt zijn om een masterkandidaat te worden.
Beide lijsten kunnen worden gedefinieerd in het cmon-configuratiebestand voor een bepaalde cluster. Als uw cluster bijvoorbeeld id '1' heeft, wilt u '/etc/cmon.d/cmon_1.cnf' bewerken. Voor witte lijst gebruikt u de variabele 'replication_failover_whitelist', voor zwarte lijst is dit een 'replication_failover_blacklist'. Beide accepteren een door komma's gescheiden lijst van 'host:port'.
Laten we eens kijken naar de volgende replicatie-instellingen. We hebben een actieve master (10.0.0.141) met twee replica's (10.0.0.142 en 10.0.0.143), beide fungeren als tussenliggende masters en hebben elk één replica (10.0.0.144 en 10.0.0.147). We hebben ook een standby-master in een apart datacenter (10.0.0.145) met een replica (10.0.0.146). Die hosts zijn bedoeld om te worden gebruikt in geval van een ramp. Replica's 10.0.0.146 en 10.0.0.147 fungeren als back-uphosts. Zie onderstaand screenshot.
Aangezien het tweede datacenter alleen bedoeld is voor noodherstel, willen we niet dat een van die hosts wordt gepromoot als master. In het ergste geval ondernemen we handmatige actie. De infrastructuur van het tweede datacenter is niet geschaald naar de grootte van het productiedatacenter (er zijn drie replica's minder in het DR-datacenter), dus handmatige acties zijn sowieso nodig voordat we een host in het DR-datacenter kunnen promoten. We willen ook niet dat een back-upreplica (10.0.0.147) wordt gepromoot. We willen ook niet dat een derde replica in de keten als master wordt opgepikt (ook al zou het kunnen met GTID).
Witte lijstconfiguratie
We kunnen een witte lijst of een zwarte lijst configureren om ervoor te zorgen dat de failover naar onze wens wordt afgehandeld. In deze specifieke opstelling kan het gebruik van een witte lijst geschikter zijn - we zullen bepalen welke hosts kunnen worden gebruikt voor failover en als iemand een nieuwe host aan de opstelling toevoegt, wordt deze niet in overweging genomen als hoofdkandidaat totdat iemand handmatig beslist dat dit het geval is ok om het te gebruiken en toe te voegen aan de witte lijst. Als we een zwarte lijst zouden gebruiken, zou het toevoegen van een nieuwe replica ergens in de keten kunnen betekenen dat een dergelijke replica in theorie automatisch kan worden gebruikt voor failover, tenzij iemand expliciet zegt dat het niet kan worden gebruikt. Laten we aan de veilige kant blijven en een witte lijst definiëren in ons clusterconfiguratiebestand (in dit geval is het /etc/cmon.d/cmon_1.cnf aangezien we maar één cluster hebben):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306We moeten ervoor zorgen dat het cmon-proces opnieuw is gestart om wijzigingen toe te passen:
service cmon restartLaten we aannemen dat onze master is gecrasht en niet kan worden bereikt door ClusterControl. Er wordt een failover-taak gestart:
De topologie ziet er als volgt uit:
Zoals u kunt zien, is de oude master uitgeschakeld en zal ClusterControl niet proberen deze automatisch te herstellen. Het is aan de gebruiker om te controleren wat er is gebeurd, alle gegevens te kopiëren die mogelijk niet naar de masterkandidaat zijn gerepliceerd en de oude master opnieuw op te bouwen:
Dan is het een kwestie van een paar topologiewijzigingen en kunnen we de topologie terugbrengen naar de oorspronkelijke staat, door 10.0.0.141 te vervangen door 10.0.0.142:
Zwarte lijstconfiguratie
Nu gaan we kijken hoe de zwarte lijst werkt. We hebben vermeld dat dit in ons voorbeeld misschien niet de beste optie is, maar we zullen het ter illustratie proberen. We zullen elke host op de zwarte lijst zetten, behalve 10.0.0.141, 10.0.0.142 en 10.0.0.143, aangezien dit de hosts zijn die we als masterkandidaten willen zien.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306We zullen ook het cmon-proces opnieuw starten om configuratiewijzigingen toe te passen:
service cmon restartHet failoverproces is vergelijkbaar. Nogmaals, zodra de hoofdcrash is gedetecteerd, start ClusterControl een failover-taak.
Wanneer een replica misschien geen goede masterkandidaat is
In dit korte gedeelte willen we enkele van de gevallen waarin u een bepaalde replica misschien niet wilt promoten om een nieuwe master te worden, in meer detail bespreken. Hopelijk geeft dit u een idee van de gevallen waarin u wellicht moet overwegen om meer handmatige controle over het failover-proces in te voeren.
Andere MySQL-versie
Ten eerste, als uw replica een andere MySQL-versie gebruikt dan de master, is het geen goed idee om deze te promoten. Over het algemeen is een recentere versie altijd een no-go, omdat replicatie van de nieuwe naar de oude MySQL-versie niet wordt ondersteund en mogelijk niet correct werkt. Dit is vooral relevant voor hoofdversies (bijvoorbeeld 8.0 replicerend naar 5.7), maar het is een goede gewoonte om deze setup helemaal te vermijden, zelfs als we het hebben over kleine versieverschillen (5.7.x+1 -> 5.7.x). Repliceren van een lagere naar een hogere/nieuwere versie wordt ondersteund omdat het een must is voor het upgradeproces, maar toch wilt u dit liever vermijden (als uw master bijvoorbeeld op 5.7.x+1 staat, vervangt u deze liever niet met een replica op 5.7.x).
Verschillende rollen
U kunt verschillende rollen aan uw replica's toewijzen. U kunt er een kiezen die beschikbaar is voor ontwikkelaars om hun query's op een productiedataset te testen. U kunt er een gebruiken voor OLAP-werkbelasting. U kunt een van hen gebruiken voor back-ups. Wat het ook is, normaal gesproken zou je zo'n replica niet willen promoten om onder de knie te krijgen. Al die extra, niet-standaard workloads kunnen prestatieproblemen veroorzaken vanwege de extra overhead. Een goede keuze voor een masterkandidaat is een replica die "normale" belasting verwerkt, min of meer hetzelfde type belasting als de huidige master. U kunt er dan zeker van zijn dat het de hoofdbelasting na een failover zal afhandelen als het het daarvoor heeft afgehandeld.
Verschillende hardwarespecificaties
We noemden verschillende rollen voor replica's. Het is niet ongebruikelijk om ook verschillende hardwarespecificaties te zien, vooral in combinatie met verschillende rollen. Een back-upslave hoeft bijvoorbeeld waarschijnlijk niet zo krachtig te zijn als een gewone replica. Ontwikkelaars kunnen hun zoekopdrachten ook testen op een langzamere database dan de productie (voornamelijk omdat u niet hetzelfde niveau van gelijktijdigheid zou verwachten bij de ontwikkeling en de productiedatabase) en bijvoorbeeld het aantal CPU-cores kan worden verminderd. Opstellingen voor noodherstel kunnen ook worden verkleind als hun belangrijkste rol zou zijn om de replicatie bij te houden en de verwachting is dat de DR-configuratie moet worden geschaald (zowel verticaal, door de instantie te vergroten als horizontaal, door meer replica's toe te voegen) voordat het verkeer ernaar kan worden omgeleid.
Vertraagde replica's
Sommige replica's kunnen vertraging oplopen - het is een zeer goede manier om de hersteltijd te verkorten als er gegevens verloren zijn gegaan, maar het maakt ze tot zeer slechte masterkandidaten. Als een replica 30 minuten vertraging heeft, verliest u ofwel die 30 minuten aan transacties of moet u wachten (waarschijnlijk geen 30 minuten omdat de replica hoogstwaarschijnlijk sneller kan inhalen) totdat de replica alle vertraagde transacties toepast. Met ClusterControl kunt u kiezen of u wilt wachten of onmiddellijk een failover wilt uitvoeren, maar dit zou goed werken voor een zeer kleine vertraging - hoogstens tientallen seconden. Als een failover minuten zou moeten duren, heeft het geen zin om zo'n replica te gebruiken en daarom is het een goed idee om deze op de zwarte lijst te zetten.
Ander datacenter
We noemden verkleinde DR-configuraties, maar zelfs als uw tweede datacenter is geschaald naar de omvang van de productie, kan het toch een goed idee zijn om de failovers binnen één enkele DC te houden. Om te beginnen kunnen uw actieve toepassingshosts zich in het hoofddatacenter bevinden, dus het verplaatsen van de master naar een stand-by-DC zou de latentie voor schrijfquery's aanzienlijk verhogen. Ook in het geval van een netwerksplitsing, wilt u deze situatie mogelijk handmatig afhandelen. MySQL heeft geen ingebouwd quorummechanisme, daarom is het nogal lastig om (op een automatische manier) netwerkverlies tussen twee datacenters correct af te handelen.