Automatiserad failover är i stort sett ett måste för många applikationer - drifttid tas för givet. Det är ganska svårt att acceptera att en ansökan ligger nere i 20 eller 30 minuter eftersom någon måste sökas för att logga in och undersöka situationen innan man vidtar åtgärder.
I den verkliga världen tenderar replikeringsinställningarna att växa med tiden och bli komplexa, ibland röriga. Och det finns begränsningar. Till exempel är inte varje nod i en installation en bra masterkandidat. Kanske är hårdvaran annorlunda och vissa av replikerna har mindre kraftfull hårdvara eftersom de är dedikerade för att hantera vissa specifika typer av arbetsbelastning? Kanske är du mitt uppe i migreringen till en ny MySQL-version och några av slavarna har redan uppgraderats? Du vill helst inte ha en mästare i nyare versioner som replikerar till gamla repliker, eftersom detta kan bryta replikeringen. Om du har två datacenter, ett aktivt och ett för katastrofåterställning, kanske du föredrar att bara välja masterkandidater i det aktiva datacentret, för att hålla mastern nära applikationsvärdarna. Det är bara exempel på situationer där du kan behöva manuellt ingripa under failover-processen. Lyckligtvis har många failover-verktyg ett alternativ att ta kontroll över processen genom att använda vitlistor och svartlistor. I det här blogginlägget vill vi visa dig några exempel på hur du kan påverka ClusterControls algoritm för att välja masterkandidater.
Konfiguration av vitlista och svartlista
ClusterControl ger dig ett alternativ att definiera både vitlista och svartlista med repliker. En vitlista är en lista över repliker som är avsedda att bli masterkandidater. Om ingen av dem är tillgängliga (antingen för att de ligger nere, eller det finns felaktiga transaktioner eller det finns andra hinder som hindrar någon av dem från att främjas), kommer failover inte att utföras. På så sätt kan du definiera vilka värdar som är tillgängliga för att bli en masterkandidat. Svarta listor, å andra sidan, definierar vilka repliker som inte är lämpliga för att bli en masterkandidat.
Båda dessa listor kan definieras i cmon-konfigurationsfilen för ett givet kluster. Till exempel, om ditt kluster har id för '1', vill du redigera '/etc/cmon.d/cmon_1.cnf'. För vitlista kommer du att använda variabeln 'replication_failover_whitelist', för svartlista kommer det att vara en 'replication_failover_blacklist'. Båda accepterar en kommaseparerad lista med 'värd:port'.
Låt oss överväga följande replikeringsinställningar. Vi har en aktiv master (10.0.0.141) som har två repliker (10.0.0.142 och 10.0.0.143), båda fungerar som mellanliggande master och har en replik vardera (10.0.0.144 och 10.0.0.147). Vi har även en standby-master i ett separat datacenter (10.0.0.145) som har en replika (10.0.0.146). Dessa värdar är avsedda att användas i händelse av en katastrof. Replikerna 10.0.0.146 och 10.0.0.147 fungerar som backup-värdar. Se skärmbilden nedan.
Med tanke på att det andra datacentret endast är avsett för katastrofåterställning vill vi inte att någon av dessa värdar ska marknadsföras som master. I värsta fall kommer vi att vidta manuella åtgärder. Det andra datacentrets infrastruktur är inte skalad till storleken på produktionsdatacentret (det finns tre kopior färre i DR-datacentret), så manuella åtgärder krävs ändå innan vi kan marknadsföra en värd i DR-datacentret. Vi vill inte heller att en backup-replik (10.0.0.147) ska marknadsföras. Vi vill inte heller att en tredje replik i kedjan ska plockas upp som en master (även om det skulle kunna göras med GTID).
Konfiguration av vitlista
Vi kan konfigurera antingen vitlista eller svartlista för att säkerställa att failover kommer att hanteras enligt vår smak. I just den här installationen kan det vara lämpligare att använda vitlista - vi kommer att definiera vilka värdar som kan användas för failover och om någon lägger till en ny värd till installationen, kommer den inte att tas under övervägande som masterkandidat förrän någon manuellt bestämmer att det är ok att använda den och lägga till den i vitlistan. Om vi använde svartlista, kan en ny replika läggas till någonstans i kedjan innebära att en sådan replik teoretiskt sett kan användas automatiskt för failover om inte någon uttryckligen säger att den inte kan användas. Låt oss vara på den säkra sidan och definiera en vitlista i vår klusterkonfigurationsfil (i det här fallet är det /etc/cmon.d/cmon_1.cnf eftersom vi bara har ett kluster):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Vi måste se till att cmon-processen har startats om för att tillämpa ändringar:
service cmon restartLåt oss anta att vår master har kraschat och inte kan nås av ClusterControl. Ett failover-jobb kommer att initieras:
Topologin kommer att se ut som nedan:
Som du kan se är den gamla mastern inaktiverad och ClusterControl kommer inte att försöka återställa den automatiskt. Det är upp till användaren att kontrollera vad som har hänt, kopiera all data som kanske inte har replikerats till masterkandidaten och bygga om den gamla mastern:
Sedan är det en fråga om några topologiändringar och vi kan föra topologin till det ursprungliga tillståndet genom att bara ersätta 10.0.0.141 med 10.0.0.142:
Konfiguration av svartlista
Nu ska vi se hur svartlistan fungerar. Vi nämnde att i vårt exempel kanske det inte är det bästa alternativet men vi kommer att prova det för illustrationens skull. Vi kommer att svartlista alla värdar utom 10.0.0.141, 10.0.0.142 och 10.0.0.143 eftersom det är värdarna vi vill se som masterkandidater.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Vi kommer också att starta om cmon-processen för att tillämpa konfigurationsändringar:
service cmon restartFailover-processen är liknande. Återigen, när huvudkraschen har upptäckts kommer ClusterControl att starta ett failover-jobb.
När en replik kanske inte är en bra masterkandidat
I detta korta avsnitt skulle vi vilja diskutera mer detaljerat några av de fall där du kanske inte vill marknadsföra en viss replik för att bli en ny mästare. Förhoppningsvis kommer detta att ge dig några idéer om de fall där du kan behöva överväga att inducera mer manuell kontroll av failover-processen.
Olik MySQL-version
För det första, om din replik använder en annan MySQL-version än mastern, är det inte en bra idé att marknadsföra den. Generellt sett är en nyare version alltid en no-go eftersom replikering från den nya till den gamla MySQL-versionen inte stöds och kanske inte fungerar korrekt. Detta är mest relevant för större versioner (till exempel 8.0 som replikerar till 5.7) men den goda praxisen är att undvika denna inställning helt, även om vi talar om små versionsskillnader (5.7.x+1 -> 5.7.x). Replikering från lägre till högre/nyare version stöds eftersom det är ett måste för uppgraderingsprocessen, men ändå vill du helst undvika detta (om din master till exempel är på 5.7.x+1 vill du helst inte byta ut den med en replika på 5.7.x).
Olika roller
Du kan tilldela olika roller till dina repliker. Du kan välja att en av dem ska vara tillgänglig för utvecklare att testa sina frågor på en produktionsdatauppsättning. Du kan använda en av dem för OLAP-arbetsbelastning. Du kan använda en av dem för säkerhetskopiering. Oavsett vad det är, vanligtvis skulle du inte vilja marknadsföra en sådan replik för att behärska. Alla dessa extra, icke-standardiserade arbetsbelastningar kan orsaka prestandaproblem på grund av den extra omkostnaden. Ett bra val för en masterkandidat är en replika som hanterar "normal" last, mer eller mindre samma typ av last som den nuvarande mastern. Du kan då vara säker på att den kommer att hantera huvudbelastningen efter failover om den hanterade den innan dess.
Olika hårdvaruspecifikationer
Vi nämnde olika roller för repliker. Det är inte ovanligt att se olika hårdvaruspecifikationer också, särskilt i samband med olika roller. Till exempel behöver en backupslav troligen inte vara lika kraftfull som en vanlig replik. Utvecklare kan också testa sina frågor på en långsammare databas än produktionen (mest för att du inte förväntar dig samma nivå av samtidighet på utvecklings- och produktionsdatabasen) och till exempel kan antalet CPU-kärnor minskas. Katastrofåterställningsinställningar kan också minskas i storlek om deras huvudsakliga roll skulle vara att hänga med i replikeringen och det förväntas att DR-installationen måste skalas (både vertikalt, genom att dimensionera instansen och horisontellt, genom att lägga till fler repliker) innan trafik kan omdirigeras till den.
Försenade repliker
Vissa av replikerna kan bli försenade - det är ett mycket bra sätt att minska återställningstiden om data har gått förlorade, men det gör dem till mycket dåliga masterkandidater. Om en replik är försenad med 30 minuter kommer du antingen att förlora de 30 minuterna av transaktioner eller så måste du vänta (förmodligen inte 30 minuter eftersom repliken sannolikt kan komma ikapp snabbare) för att repliken ska tillämpa alla försenade transaktioner. ClusterControl låter dig välja om du vill vänta eller om du vill göra failover omedelbart, men det här skulle fungera ok för en mycket liten fördröjning - högst tiotals sekunder. Om failover är tänkt att ta några minuter är det ingen idé att använda en sådan replik och därför är det en bra idé att svartlista den.
Annat datacenter
Vi nämnde nedskalade DR-inställningar, men även om ditt andra datacenter är skalat till produktionsstorleken, kan det fortfarande vara en bra idé att endast hålla failovers inom en enda DC. Till att börja med kan dina aktiva applikationsvärdar vara placerade i huvuddatacentret, så att flytta mastern till en standby DC skulle avsevärt öka latensen för skrivfrågor. Dessutom, i händelse av en nätverksdelning, kanske du vill hantera denna situation manuellt. MySQL har ingen inbyggd kvorummekanism, därför är det lite knepigt att korrekt hantera (på ett automatiskt sätt) nätverksförlust mellan två datacenter.