Databasbyte och failover för Drupal-webbplatser som använder MySQL eller PostgreSQL

Drupal är ett innehållshanteringssystem (CMS) designat för att skapa allt från små till stora företagswebbplatser. Över 1 000 000 webbplatser körs på Drupal och det används för att göra många av de webbplatser och applikationer du använder varje dag (inklusive den här). Drupal har en stor uppsättning standardfunktioner som enkel innehållsförfattande, pålitlig prestanda och utmärkt säkerhet. Det som skiljer Drupal åt är dess flexibilitet eftersom modularitet är en av dess kärnprinciper.

Drupal är också ett utmärkt val för att skapa integrerade digitala ramverk. Du kan utöka den med de tusentals tillägg som finns tillgängliga. Dessa moduler utökar Drupals funktionalitet. Teman låter dig anpassa ditt innehålls presentation och distributioner (Drupal-buntar) är paket som du kan använda som startpaket. Du kan använda alla dessa funktioner för att mixa och matcha för att förbättra Drupals kärnförmågor eller för att integrera Drupal med externa tjänster. Det är programvara för innehållshantering som är kraftfull och skalbar.

Drupal använder databaser för att lagra sitt webbinnehåll. När din Drupal-baserade webbplats eller applikation upplever en stor mängd trafik kan det ha en inverkan på din databasserver. När du är i den här situationen behöver du lastbalansering, hög tillgänglighet och en redundant arkitektur för att hålla din databas online.

När jag började efterforska den här bloggen insåg jag att det finns många svar på det här problemet online, men de rekommenderade lösningarna var mycket föråldrade. Detta kan vara ett resultat av att WordPress ökade marknadsandelar som resulterar i en mindre community med öppen källkod. Vad jag hittade var några exempel på att implementera hög tillgänglighet genom att använda Master/Master (Hög tillgänglighet) eller Master/Master/Slav (Hög tillgänglighet/Hög prestanda).

Drupal erbjuder stöd för ett brett utbud av databaser, men det designades från början med MySQL-varianter. Även om användning av MySQL stöds fullt ut, finns det bättre metoder du kan implementera. Att implementera dessa andra tillvägagångssätt kan dock, om det inte görs på rätt sätt, få din webbplats att uppleva stora mängder driftstopp, få din applikation att drabbas av prestandaproblem och kan resultera i skrivproblem till dina slavar. Att utföra underhåll skulle också vara svårt eftersom du behöver failover för att tillämpa serveruppgraderingarna eller patchar (hårdvara eller mjukvara) utan driftstopp. Detta gäller särskilt om du har en stor mängd data, vilket kan orsaka en potentiell stor påverkan på ditt företag.

Det här är situationer som du inte vill ska hända och det är därför vi i den här bloggen kommer att diskutera hur du kan implementera databas-failover för dina MySQL- eller PostgreSQL-databaser.

Varför behöver din Drupal-webbplats databasfel?

Från Wikipedia “felövergång är att byta till en redundant eller standby-datorserver, system, hårdvarukomponent eller nätverk vid fel eller onormal avslutning av den tidigare aktiva applikationen, servern, systemet, hårdvarukomponenten eller nätverket. Failover och switchover är i huvudsak samma operation, förutom att failover är automatisk och vanligtvis fungerar utan förvarning, medan omkoppling kräver mänskligt ingripande.”

I databasoperationer är switchover också en term som används för manuell failover, vilket betyder att det kräver att en person hanterar failover. Failover är praktiskt för alla administratörer eftersom det isolerar oönskade problem som oavsiktliga raderingar/borttagning av tabeller, långa timmars driftstopp som orsakar affärspåverkan, databaskorruption eller korruption på systemnivå.

Databasfailover består av mer än en enda databasnod, antingen fysiskt eller virtuellt. Helst, eftersom failover kräver att du byter över till en annan nod, kan du lika gärna byta till en annan databasserver, om en värd kör flera databasinstanser på en enda värd. Det kan fortfarande vara antingen övergång eller failover, men vanligtvis handlar det mer om redundans och hög tillgänglighet om en katastrof inträffar på den aktuella värden.

MySQL-failover för Drupal

Att utföra en failover för din Drupal-baserade applikation kräver att data som hanteras av databasen inte särskiljs eller separeras. Det finns flera tillgängliga lösningar, och vi har redan diskuterat några av dem i tidigare Severalnines-bloggar. Du kanske vill läsa vår Introduktion till Failover för MySQL-replikering - 101-bloggen.

Master-Slave-övergången

De vanligaste tillvägagångssätten för MySQL Failover är att använda master-slave switch-over eller manuell failover. Det finns två metoder du kan göra här:

• Du kan implementera din databas med en typisk asynkron master-slav-replikering.
• eller kan implementera med asynkron master-slave-replikering med GTID-baserad replikering.

Att byta till en annan master kan vara snabbare och enklare. Detta kan göras med följande MySQL-syntax:

mysql> SET GLOBAL read_only = 1; /* enable read-only */

mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */

mysql> START SLAVE; /* start replication */

mysql> SHOW SLAVE STATUS\G /* check replication status */

eller med GTID kan du helt enkelt göra,

...

mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */

...

Wit

Användning av icke-GTID-metoden kräver att du först bestämmer masterns loggfil och masterns loggpos. Du kan fastställa detta genom att titta på masterns status i masternoden innan du byter över.

mysql> MASTER STATUS;

Du kan också överväga att härda din server genom att lägga till sync_binlog =1 och innodb_flush_log_at_trx_commit =1 eftersom, i händelse av att din master kraschar, har du en större chans att transaktioner från master kommer att vara osynkroniserade med din slav( s). I ett sådant fall har den befordrade mastern en större chans att vara en konsekvent datakällanod.

Detta är dock kanske inte det bästa tillvägagångssättet för din Drupal-databas eftersom det kan leda till långa driftstopp om det inte utförs på rätt sätt, som att plötsligt tas ner. Om din huvuddatabasnod upplever en bugg som resulterar i att en databas kraschar, behöver du att din applikation pekar på en annan databas som väntar i vänteläge som din nya master eller genom att din slav befordras till att bli master. Du måste ange exakt vilken nod som ska ta över och sedan bestämma fördröjningen och konsistensen för den noden. Att uppnå detta är inte så lätt som att bara göra SET GLOBAL read_only=1; ÄNDRA MASTER TILL... (etc.), det finns vissa situationer som kräver djupare analys, genom att titta på de genomförbara transaktioner som krävs för att vara närvarande i den standby-servern eller befordrade mastern för att få det gjort.

Drupal-failover med MHA

Ett av de vanligaste verktygen för automatisk och manuell failover är MHA. Det har funnits länge nu och används fortfarande av många organisationer. Du kan kolla in dessa tidigare bloggar vi har om ämnet, vanligaste problem med MHA och hur man åtgärdar dem eller MySQL High Availability Tools - Comparing MHA, MRM och ClusterControl.

Drupal-failover med Orchestrator

Orchestrator har blivit allmänt adopterad nu och används av stora organisationer som Github och Booking.com. Det låter dig inte bara hantera en failover, utan även topologihantering, värdupptäckt, refaktorering och återställning. Det finns en trevlig extern blogg här som jag tyckte var mycket användbar att lära mig om dess failover-mekanism med Orchestrator. Det är en bloggserie i två delar; del ett och del två.

Drupal-failover med MaxScale

MaxScale är inte bara en lastbalanserare designad för MariaDB-servern, den utökar också hög tillgänglighet, skalbarhet och säkerhet för MariaDB samtidigt som den förenklar applikationsutvecklingen genom att frikoppla den från underliggande databasinfrastruktur. Om du använder MariaDB kan MaxScale vara en relevant teknik för dig. Kolla in våra tidigare bloggar om hur du kan använda MaxScale failover-mekanismen.

Drupal-failover med ClusterControl

Severalnines ClusterControl erbjuder ett brett utbud av databashanterings- och övervakningslösningar. En del av lösningarna vi erbjuder är automatisk failover, manuell failover och kluster/nodåterställning. Detta är mycket användbart som om det fungerar som din virtuella databasadministratör, och meddelar dig i realtid om ditt kluster är i "panikläge", allt medan återställningen hanteras av systemet. Du kan kolla in den här bloggen Hur man automatiserar databasfailover med ClusterControl för att lära dig mer om ClusterControl-failover.

Andra MySQL-lösningar

Några av de gamla metoderna är fortfarande tillämpliga när du vill göra en failover. Det finns MMM, MRM, eller så kan du kolla in Group Replication eller Galera (obs:Galera använder inte asynkron, snarare synkron replikering). Failover i ett Galera-kluster fungerar inte på samma sätt som det gör med asynkron replikering. Med Galera kan du bara skriva till vilken nod som helst eller, om du implementerar ett master-slave-tillvägagångssätt, kan du dirigera din ansökan till en annan nod som kommer att vara den aktiva skrivaren för klustret.

Drupal PostgreSQL-failover

Eftersom Drupal stöder PostgreSQL kommer vi också att kolla in verktygen för att implementera en failover- eller omställningsprocess för PostgreSQL. PostgreSQL använder inbyggd streamingreplikering, men du kan också ställa in den att använda en logisk replikering (läggs till som ett kärnelement i PostgreSQL i version 10).

Drupal-failover med pg_ctlcluster

Om din miljö är Ubuntu är användningen av pg_ctlcluster ett enkelt och enkelt sätt att uppnå failover. Du kan till exempel bara köra följande kommando:

$ pg_ctlcluster 9.6 pg_7653 promote

eller med RHEL/Centos kan du använda kommandot pg_ctl precis som,

$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D  /data/pgsql/slave/data

server promoting

Du kan också utlösa failover för en standbyserver för loggsändning genom att skapa en triggerfil med filnamnet och sökvägen som anges av trigger_filen i recovery.conf.

Du måste vara försiktig med standby-befordran eller slavbefordran här eftersom du kanske måste se till att endast en master accepterar läs-skriv-begäran. Detta innebär att när du gör omställningen kan du behöva se till att den tidigare mastern har kopplats av eller stoppats.

Att ta hand om övergången eller manuell övergång från primär till standby-server kan gå snabbt, men det tar lite tid att förbereda övergångsklustret igen. Att regelbundet byta från primär till standby är en användbar praxis eftersom det tillåter regelbundna driftstopp på varje system för underhåll. Detta fungerar också som ett test av failover-mekanismen, för att säkerställa att den verkligen kommer att fungera när du behöver den. Skriftliga administrativa rutiner rekommenderas alltid.

Drupal PostgreSQL Automatic Failover

Istället för ett manuellt tillvägagångssätt, kan du kräva automatisk failover. Detta behövs särskilt när en server går ner på grund av maskinvarufel eller korruption av virtuell maskin. Du kan också kräva att ett program automatiskt utför failover för att minska stilleståndstiden för din Drupal-applikation. Vi ska nu gå igenom några av dessa verktyg som kan användas för automatisk failover.

Drupal-failover med Patroni

Patroni är en mall för dig att skapa din egen anpassade, högtillgängliga lösning med Python och - för maximal tillgänglighet - en distribuerad konfigurationsbutik som ZooKeeper, etcd, Consul eller Kubernetes. Databasingenjörer, DBA:er, DevOps-ingenjörer och SRE:er som snabbt vill distribuera HA PostgreSQL i datacentret - eller någon annanstans - kommer förhoppningsvis att finna det användbart

Drupal-failover med Pgpool

Pgpool-II är en proxyprogramvara som sitter mellan PostgreSQL-servrarna och en PostgreSQL-databasklient. Förutom att ha en automatisk failover, har den flera funktioner som inkluderar anslutningspooling, lastbalansering, replikering och begränsning av överskridande anslutningar. Du kan läsa mer om detta verktyg är vår tredelade blogg; del ett, del två, del tre.

Drupal-failover med pglookout

pglookout är en PostgreSQL-replikeringsövervakning och failover-demon. pglookout övervakar databasnoderna, deras replikeringsstatus och agerar enligt den statusen. Till exempel att anropa ett fördefinierat failover-kommando för att främja en ny master om den tidigare försvinner.

pglookout stöder två olika nodtyper, de som är installerade på själva db-noderna och observatörsnoder som kan installeras var som helst. Syftet med att ha pglookout på PostgreSQL DB-noderna är att övervaka replikeringsstatusen för klustret och agera därefter, observatörerna har ett mer begränsat uppdrag:de observerar bara klusterstatusen för att ge en annan synvinkel till klustertillståndet.

Drupal-failover med repmgr

repmgr är en öppen källkodssvit för att hantera replikering och failover i ett kluster av PostgreSQL-servrar. Det förbättrar PostgreSQL:s inbyggda hot-standby-funktioner med verktyg för att ställa in standby-servrar, övervaka replikering och utföra administrativa uppgifter som failover eller manuella övergångsoperationer.

repmgr har tillhandahållit avancerat stöd för PostgreSQL:s inbyggda replikeringsmekanismer sedan de introducerades i 9.0. Den nuvarande repmgr-serien, repmgr 4, stöder den senaste utvecklingen av replikeringsfunktionalitet som introducerats från PostgreSQL 9.3, såsom kaskadreplikering, tidslinjebyte och bassäkerhetskopiering via replikeringsprotokollet.

Drupal-failover med ClusterControl

ClusterControl stöder automatisk failover för PostgreSQL. Om du har en incident kan din slav automatiskt befordras till masterstatus. Med ClusterControl kan du också distribuera fristående, replikerade eller klustrade PostgreSQL-databas. Du kan också enkelt lägga till eller ta bort en nod med en enda åtgärd.

Andra PostgreSQL Drupal failover-lösningar

Det finns säkerligen automatiska failover-lösningar som jag kan ha missat på den här bloggen. Om jag gjorde det, vänligen lägg till dina kommentarer nedan så att vi kan känna till dina tankar och erfarenheter av din implementering och installation av failover, speciellt för Drupal-webbplatser eller applikationer.

Ytterligare lösningar för Drupal-failover

Medan verktygen jag har nämnt tidigare definitivt hanterar lösningen för dina problem med failover, kan det vara tillfredsställande att lägga till några verktyg som gör failover ganska enklare, säkrare och har en total isolering mellan ditt databaslag.

Drupal-failover med ProxySQL

Med ProxySQL kan du bara peka dina Drupal-webbplatser eller applikationer till ProxySQL-servervärden och den kommer att ange vilken nod som kommer att ta emot skrivningar och vilka noder som kommer att ta emot läsningarna. Magin sker transparent inom TCP-lagret och inga ändringar behövs för din applikation/webbplatskonfiguration. Utöver det fungerar ProxySQL också som din lastbalanserare för dina skriv- och läsbegäranden för din databastrafik. Detta är endast tillämpligt om du använder MySQL-databasvarianter.

Drupal Failover med HAProxy med Keepalived

Att använda HAProxy och Keepalved ger mer hög tillgänglighet och redundans i din Drupals databas. Om du vill göra failover kan det göras utan att din applikation vet vad som händer i ditt databaslager. Rikta bara din applikation till den vrrp-IP som du ställer in i din Keepalived så kommer allt att hanteras med total isolering från din applikation. Att ha en automatisk failover kommer att hanteras transparent och omedvetet av din applikation så inga ändringar behöver ske när till exempel en katastrof har inträffat och en återställning eller failover har tillämpats. Det som är bra med den här installationen är att den är tillämplig för både MySQL- och PostgreSQL-databaser. Jag föreslår att du kollar in vår blogg PostgreSQL Load Balancing Using HAProxy &Keepalived för att lära dig mer om hur du gör detta.

Alla alternativen ovan stöds av ClusterControl. Du kan distribuera eller importera databasen och sedan distribuera ProxySQL, MaxScale eller HAProxy &Keepalved. Allt kommer att hanteras, övervakas och kommer att ställas in automatiskt utan att du behöver någon ytterligare konfiguration. Allt sker i bakgrunden och skapar automatiskt en färdig för produktion.

Slutsats

Att ha en Drupal-webbplats eller -applikation som alltid är aktiv, särskilt om du förväntar dig en stor mängd trafik, kan vara komplicerat att skapa. Om du har rätt verktyg, rätt inställning och rätt teknikstack är det dock möjligt att uppnå hög tillgänglighet och redundans.

Och om du inte gör det? Då kommer ClusterControl att ställa in det och underhålla det åt dig. Alternativt kan du skapa en konfiguration med hjälp av teknikerna som nämns i den här bloggen, av vilka de flesta är gratisverktyg med öppen källkod som kan tillgodose dina behov.