Database-omschakeling en failover voor Drupal-websites met MySQL of PostgreSQL

Drupal is een Content Management Systeem (CMS) dat is ontworpen om alles te maken, van kleine tot grote zakelijke websites. Meer dan 1.000.000 websites draaien op Drupal en het wordt gebruikt om veel van de websites en applicaties te maken die u dagelijks gebruikt (inclusief deze). Drupal heeft een groot aantal standaardfuncties, zoals het eenvoudig schrijven van inhoud, betrouwbare prestaties en uitstekende beveiliging. Wat Drupal onderscheidt, is de flexibiliteit, aangezien modulariteit een van de kernprincipes is.

Drupal is ook een uitstekende keuze voor het maken van geïntegreerde digitale frameworks. U kunt het uitbreiden met de duizenden beschikbare add-ons. Deze modules breiden de functionaliteit van Drupal uit. Met thema's kunt u de presentatie en distributie van uw inhoud aanpassen (Drupal-bundels) zijn bundels die u als starterkits kunt gebruiken. Je kunt al deze functionaliteiten gebruiken om te mixen en matchen om de kerncapaciteiten van Drupal te verbeteren of om Drupal te integreren met externe diensten. Het is contentmanagementsoftware die krachtig en schaalbaar is.

Drupal gebruikt databases om zijn webinhoud op te slaan. Wanneer uw op Drupal gebaseerde website of applicatie veel verkeer ervaart, kan dit een impact hebben op uw databaseserver. Wanneer u zich in deze situatie bevindt, heeft u taakverdeling, hoge beschikbaarheid en een redundante architectuur nodig om uw database online te houden.

Toen ik begon met het onderzoeken van deze blog, realiseerde ik me dat er veel antwoorden op dit probleem online zijn, maar de aanbevolen oplossingen waren erg gedateerd. Dit kan een gevolg zijn van de toename van het marktaandeel door WordPress, wat resulteert in een kleinere open source-community. Wat ik wel vond, waren enkele voorbeelden van het implementeren van hoge beschikbaarheid door Master/Master (hoge beschikbaarheid) of master/master/slave (hoge beschikbaarheid/hoge prestaties) te gebruiken.

Drupal biedt ondersteuning voor een breed scala aan databases, maar het werd oorspronkelijk ontworpen met MySQL-varianten. Hoewel het gebruik van MySQL volledig wordt ondersteund, zijn er betere benaderingen die u kunt implementeren. Het implementeren van deze andere benaderingen kan er echter toe leiden dat uw website grote hoeveelheden downtime ervaart, dat uw toepassing prestatieproblemen ondervindt en dat er schrijfproblemen ontstaan naar uw slaven, als dit niet goed wordt gedaan. Het uitvoeren van onderhoud zou ook moeilijk zijn, omdat u een failover nodig hebt om de serverupgrades of patches (hardware of software) toe te passen zonder downtime. Dit is met name het geval als u een grote hoeveelheid gegevens heeft, wat een potentieel grote impact op uw bedrijf kan hebben.

Dit zijn situaties die je niet wilt laten gebeuren. Daarom bespreken we in deze blog hoe je database-failover kunt implementeren voor je MySQL- of PostgreSQL-databases.

Waarom heeft uw Drupal-website een databasefailover nodig?

Van Wikipedia "failover is het overschakelen naar een redundante of stand-by computerserver, systeem, hardwarecomponent of netwerk bij een storing of abnormale beëindiging van de eerder actieve applicatie, server, systeem, hardwarecomponent of netwerk. Failover en omschakeling zijn in wezen dezelfde operatie, behalve dat failover automatisch is en meestal zonder waarschuwing werkt, terwijl omschakeling menselijke tussenkomst vereist.”

In databasebewerkingen is omschakeling ook een term die wordt gebruikt voor handmatige failover, wat inhoudt dat er een persoon nodig is om de failover uit te voeren. Failover is handig voor elke beheerder omdat het ongewenste problemen isoleert, zoals het per ongeluk verwijderen/laten vallen van tabellen, lange uren van downtime die gevolgen heeft voor het bedrijf, databasecorruptie of corruptie op systeemniveau.

Databasefailover bestaat uit meer dan één databaseknooppunt, fysiek of virtueel. Idealiter, aangezien failover vereist dat u overschakelt naar een ander knooppunt, kunt u net zo goed overschakelen naar een andere databaseserver als een host meerdere database-instanties op één host uitvoert. Dat kan nog steeds een omschakeling of een failover zijn, maar meestal is het meer redundantie en hoge beschikbaarheid voor het geval er zich een ramp voordoet op die huidige host.

MySQL-failover voor Drupal

Het uitvoeren van een failover voor uw op Drupal gebaseerde applicatie vereist dat de gegevens die door de database worden verwerkt, niet differentiëren of scheiden. Er zijn verschillende oplossingen beschikbaar, waarvan we er al een aantal hebben besproken in eerdere blogs van Multiplenines. Misschien wilt u onze Inleiding tot Failover voor MySQL-replicatie lezen - de 101 Blog.

De master-slave-omschakeling

De meest gebruikelijke benaderingen voor MySQL-failover is het gebruik van de master-slave-omschakeling of de handmatige failover. Er zijn twee benaderingen die u hier kunt doen:

U kunt uw database implementeren met een typische asynchrone master-slave-replicatie.
of kan worden geïmplementeerd met asynchrone master-slave-replicatie met behulp van op GTID gebaseerde replicatie.

Overschakelen naar een andere master kan sneller en gemakkelijker zijn. Dit kan met de volgende MySQL-syntaxis:

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 */

of met GTID, je kunt gewoon doen,

...

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

...

Wit

Als je de niet-GTID-benadering gebruikt, moet je eerst het logbestand van de master en de log-positie van de master bepalen. U kunt dit bepalen door vóór het overschakelen naar de status van de master in de masternode te kijken.

mysql> MASTER STATUS;

Je kunt ook overwegen om je server harder te maken door sync_binlog =1 en innodb_flush_log_at_trx_commit =1 toe te voegen, omdat, in het geval dat je master crasht, je een grotere kans hebt dat transacties van master niet synchroon lopen met je slave( s). In zo'n geval heeft de gepromoveerde master een grotere kans om een consistent gegevensbronknooppunt te zijn.

Dit is echter misschien niet de beste aanpak voor uw Drupal-database, omdat het lange downtime kan veroorzaken als het niet correct wordt uitgevoerd, zoals abrupt verwijderen. Als uw masterdatabase-knooppunt een bug ervaart die ertoe leidt dat een database crasht, moet u uw toepassing laten verwijzen naar een andere database die stand-by wacht als uw nieuwe master of door uw slave te laten promoveren tot master. U moet precies specificeren welk knooppunt het moet overnemen en vervolgens de vertraging en consistentie van dat knooppunt bepalen. Dit bereiken is niet zo eenvoudig als SET GLOBAL read_only=1; MASTER WIJZIGEN IN... (enz.), er zijn bepaalde situaties die een diepere analyse vereisen, kijkend naar de haalbare transacties die nodig zijn om aanwezig te zijn in die standby-server of gepromoveerde master, om het voor elkaar te krijgen.

Drupal-failover met MHA

Een van de meest gebruikte tools voor automatische en handmatige failover is MHA. Het bestaat al een hele tijd en wordt nog steeds door veel organisaties gebruikt. U kunt deze eerdere blogs bekijken die we hebben over dit onderwerp, de meest voorkomende problemen met MHA en hoe u ze kunt oplossen of MySQL-hulpmiddelen voor hoge beschikbaarheid - MHA, MRM en ClusterControl vergelijken.

Drupal-failover met Orchestrator

Orchestrator is nu algemeen aanvaard en wordt gebruikt door grote organisaties zoals Github en Booking.com. Hiermee kunt u niet alleen een failover beheren, maar ook topologiebeheer, hostdetectie, refactoring en herstel. Er is hier een mooie externe blog die ik erg nuttig vond om meer te weten te komen over het failover-mechanisme met Orchestrator. Het is een tweedelige blogserie; deel één en deel twee.

Drupal-failover met MaxScale

MaxScale is niet alleen een load balancer die is ontworpen voor de MariaDB-server, het vergroot ook de hoge beschikbaarheid, schaalbaarheid en beveiliging voor MariaDB en vereenvoudigt tegelijkertijd de applicatie-ontwikkeling door het los te koppelen van de onderliggende database-infrastructuur. Als u MariaDB gebruikt, kan MaxScale een relevante technologie voor u zijn. Bekijk onze eerdere blogs over hoe u het MaxScale-failovermechanisme kunt gebruiken.

Drupal-failover met ClusterControl

Severalnines' ClusterControl biedt een breed scala aan databasebeheer- en monitoringoplossingen. Een deel van de oplossingen die we bieden is automatische failover, handmatige failover en cluster/node recovery. Dit is erg handig, alsof het fungeert als uw virtuele databasebeheerder en u in realtime op de hoogte stelt als uw cluster zich in de "paniekmodus" bevindt, terwijl het herstel door het systeem wordt beheerd. U kunt deze blog Databasefailover automatiseren met ClusterControl lezen voor meer informatie over ClusterControl-failover.

Andere MySQL-oplossingen

Sommige van de oude benaderingen zijn nog steeds van toepassing wanneer u een failover wilt uitvoeren. Er is MMM, MRM, of je kunt Groepsreplicatie of Galera afrekenen (opmerking:Galera gebruikt geen asynchrone, eerder synchrone replicatie). Failover in een Galera-cluster werkt niet op dezelfde manier als bij asynchrone replicatie. Met Galera kunt u gewoon naar elk knooppunt schrijven of, als u een master-slave-aanpak implementeert, uw toepassing naar een ander knooppunt leiden dat de actieve schrijver voor het cluster zal zijn.

Drupal PostgreSQL-failover

Aangezien Drupal PostgreSQL ondersteunt, zullen we ook de tools bekijken om een failover- of omschakelingsproces voor PostgreSQL te implementeren. PostgreSQL gebruikt ingebouwde streaming-replicatie, maar u kunt het ook instellen om een logische replicatie te gebruiken (toegevoegd als een kernelement van PostgreSQL in versie 10).

Drupal-failover met pg_ctlcluster

Als uw omgeving Ubuntu is, is het gebruik van pg_ctlcluster een eenvoudige en gemakkelijke manier om een failover te bereiken. U kunt bijvoorbeeld gewoon de volgende opdracht uitvoeren:

$ pg_ctlcluster 9.6 pg_7653 promote

of met RHEL/Centos, je kunt het pg_ctl-commando gebruiken, net als,

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

server promoting

Je kunt ook een failover van een log-shipping standby-server activeren door een triggerbestand te maken met de bestandsnaam en het pad gespecificeerd door het trigger_file in recovery.conf.

Je moet hier voorzichtig zijn met standby-promotie of slave-promotie, omdat je er misschien voor moet zorgen dat slechts één master het lees-schrijfverzoek accepteert. Dit betekent dat u tijdens de omschakeling er misschien voor moet zorgen dat de vorige master ontspannen of gestopt is.

Het zorgen voor een omschakeling of handmatige failover van de primaire naar de standby-server kan snel zijn, maar het vereist enige tijd om het failovercluster opnieuw voor te bereiden. Regelmatig overschakelen van primair naar stand-by is een nuttige gewoonte omdat het zorgt voor regelmatige uitvaltijd op elk systeem voor onderhoud. Dit dient ook als een test van het failover-mechanisme, om er zeker van te zijn dat het echt werkt wanneer u het nodig hebt. Schriftelijke administratieprocedures worden altijd geadviseerd.

Drupal PostgreSQL automatische failover

In plaats van een handmatige aanpak is mogelijk automatische failover vereist. Dit is vooral nodig wanneer een server uitvalt als gevolg van hardwarestoringen of beschadiging van de virtuele machine. Mogelijk hebt u ook een toepassing nodig om de failover automatisch uit te voeren om de downtime van uw Drupal-toepassing te verminderen. We zullen nu enkele van deze tools bespreken die kunnen worden gebruikt voor automatische failover.

Drupal-failover met Patroni

Patroni is een sjabloon waarmee u uw eigen aangepaste oplossing met hoge beschikbaarheid kunt maken met Python en - voor maximale toegankelijkheid - een gedistribueerd configuratiearchief zoals ZooKeeper, etcd, Consul of Kubernetes. Database-engineers, DBA's, DevOps-engineers en SRE's die HA PostgreSQL snel willen implementeren in het datacenter of waar dan ook, zullen dit hopelijk nuttig vinden

Drupal-failover met Pgpool

Pgpool-II is proxy-software die tussen de PostgreSQL-servers en een PostgreSQL-databaseclient zit. Afgezien van een automatische failover, heeft het meerdere functies, waaronder pooling van verbindingen, taakverdeling, replicatie en het beperken van de overschrijding van verbindingen. U kunt meer over deze tool lezen in onze driedelige blog; deel één, deel twee, deel drie.

Drupal-failover met pglookout

pglookout is een PostgreSQL-replicatiebewakings- en failover-daemon. pglookout bewaakt de databaseknooppunten, hun replicatiestatus en handelt volgens die status. Bijvoorbeeld het aanroepen van een vooraf gedefinieerde failover-opdracht om een nieuwe master te promoveren in het geval dat de vorige ontbreekt.

pglookout ondersteunt twee verschillende typen knooppunten, die op de db-knooppunten zelf zijn geïnstalleerd en waarnemer-knooppunten die overal kunnen worden geïnstalleerd. Het doel van pglookout op de PostgreSQL DB-knooppunten is om de replicatiestatus van het cluster te bewaken en dienovereenkomstig te handelen. De waarnemers hebben een beperktere taak:ze observeren alleen de clusterstatus om een ander gezichtspunt te geven aan de clusterstatus.

Drupal-failover met repmgr

repmgr is een open-source toolsuite voor het beheren van replicatie en failover in een cluster van PostgreSQL-servers. Het verbetert de ingebouwde hot-standby-mogelijkheden van PostgreSQL met tools om standby-servers in te stellen, replicatie te bewaken en administratieve taken uit te voeren, zoals failover- of handmatige omschakelingsbewerkingen.

repmgr biedt sinds de introductie in 9.0 geavanceerde ondersteuning voor de ingebouwde replicatiemechanismen van PostgreSQL. De huidige repmgr-serie, repmgr 4, ondersteunt de nieuwste ontwikkelingen op het gebied van replicatiefunctionaliteit die is geïntroduceerd vanuit PostgreSQL 9.3, zoals trapsgewijze replicatie, tijdlijnwisseling en basisback-ups via het replicatieprotocol.

Drupal-failover met ClusterControl

ClusterControl ondersteunt automatische failover voor PostgreSQL. Als u een incident heeft, kan uw slaaf automatisch worden gepromoveerd tot masterstatus. Met ClusterControl kunt u ook standalone, gerepliceerde of geclusterde PostgreSQL-databases implementeren. U kunt ook eenvoudig een knooppunt toevoegen of verwijderen met een enkele handeling.

Andere PostgreSQL Drupal Failover-oplossingen

Er zijn zeker automatische failover-oplossingen die ik op deze blog heb gemist. Als dat het geval is, voeg dan hieronder uw opmerkingen toe, zodat we uw mening en ervaringen met uw implementatie en instelling voor failover kunnen kennen, vooral voor Drupal-websites of -toepassingen.

Aanvullende oplossingen voor Drupal-failover

Hoewel de tools die ik eerder heb genoemd zeker de oplossing bieden voor je problemen met failover, kan het bevredigend zijn om wat tools toe te voegen die de failover behoorlijk eenvoudiger en veiliger maken en een totale isolatie tussen je databaselaag hebben.

Drupal-failover met ProxySQL

Met ProxySQL kunt u uw Drupal-websites of applicaties naar de ProxySQL-serverhost verwijzen en het zal aangeven welk knooppunt schrijfbewerkingen zal ontvangen en welke knooppunten de leesbewerkingen zullen ontvangen. De magie gebeurt transparant binnen de TCP-laag en er zijn geen wijzigingen nodig voor uw applicatie/website-configuratie. Daarnaast fungeert ProxySQL ook als uw load balancer voor uw schrijf- en leesverzoeken voor uw databaseverkeer. Dit is alleen van toepassing als u MySQL-databasevarianten gebruikt.

Drupal-failover met HAProxy met Keepalive

Het gebruik van HAProxy en Keepalive voegt meer hoge beschikbaarheid en redundantie toe aan uw Drupal-database. Als u een failover wilt uitvoeren, kan dit worden gedaan zonder dat uw toepassing weet wat er binnen uw databaselaag gebeurt. Wijs uw applicatie gewoon naar het vrrp IP-adres dat u in uw Keepalive hebt ingesteld en alles wordt behandeld met volledige isolatie van uw applicatie. Het hebben van een automatische failover wordt transparant en onbewust afgehandeld door uw applicatie, dus er hoeven geen wijzigingen plaats te vinden als er zich bijvoorbeeld een calamiteit heeft voorgedaan en een herstel of failover is toegepast. Het goede aan deze opstelling is dat deze toepasbaar is voor zowel MySQL- als PostgreSQL-databases. Ik raad je aan om onze blog PostgreSQL Load Balancing met HAProxy &Keepalive te lezen voor meer informatie over hoe je dit kunt doen.

Alle bovenstaande opties worden ondersteund door ClusterControl. U kunt de database implementeren of importeren en vervolgens ProxySQL, MaxScale of HAProxy &Keepalive implementeren. Alles wordt beheerd, gecontroleerd en automatisch ingesteld zonder dat u verdere configuratie nodig heeft. Het gebeurt allemaal op de achtergrond en er ontstaat automatisch een klaar voor productie.

Conclusie

Het kan ingewikkeld zijn om een always-on Drupal-website of -applicatie te maken, vooral als je veel verkeer verwacht. Als u echter over de juiste tools, de juiste setup en de juiste technologiestack beschikt, is het mogelijk om een hoge beschikbaarheid en redundantie te bereiken.

En als je dat niet doet? Welnu, ClusterControl zal het voor u opzetten en onderhouden. Als alternatief kunt u een installatie maken met behulp van de technologieën die in deze blog worden genoemd, waarvan de meeste open source, gratis tools zijn die aan uw behoeften voldoen.