MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Datenbankumschaltung und Failover für Drupal-Websites mit MySQL oder PostgreSQL

Drupal ist ein Content-Management-System (CMS), mit dem alles erstellt werden kann, von kleinen bis hin zu großen Unternehmens-Websites. Über 1.000.000 Websites laufen auf Drupal und es wird verwendet, um viele der Websites und Anwendungen zu erstellen, die Sie täglich verwenden (einschließlich dieser). Drupal verfügt über eine große Auswahl an Standardfunktionen wie einfaches Verfassen von Inhalten, zuverlässige Leistung und hervorragende Sicherheit. Was Drupal auszeichnet, ist seine Flexibilität, da Modularität eines seiner Kernprinzipien ist.

Drupal ist auch eine großartige Wahl für die Erstellung integrierter digitaler Frameworks. Sie können es mit Tausenden von verfügbaren Add-Ons erweitern. Diese Module erweitern die Funktionalität von Drupal. Mit Themes können Sie die Präsentation Ihrer Inhalte anpassen und Distributionen (Drupal-Bundles) sind Bundles, die Sie als Starter-Kits verwenden können. Sie können all diese Funktionalitäten kombinieren und anpassen, um die Kernfähigkeiten von Drupal zu verbessern oder Drupal mit externen Diensten zu integrieren. Es ist eine leistungsstarke und skalierbare Content-Management-Software.

Drupal verwendet Datenbanken, um seine Webinhalte zu speichern. Wenn Ihre Drupal-basierte Website oder Anwendung stark frequentiert ist, kann dies Auswirkungen auf Ihren Datenbankserver haben. In dieser Situation benötigen Sie Lastenausgleich, Hochverfügbarkeit und eine redundante Architektur, um Ihre Datenbank online zu halten.

Als ich anfing, diesen Blog zu recherchieren, stellte ich fest, dass es online viele Antworten auf dieses Problem gibt, aber die empfohlenen Lösungen sehr veraltet waren. Dies könnte ein Ergebnis der Zunahme des Marktanteils von WordPress sein, was zu einer kleineren Open-Source-Community führt. Was ich gefunden habe, waren einige Beispiele für die Implementierung von Hochverfügbarkeit durch Verwendung von Master/Master (Hochverfügbarkeit) oder Master/Master/Slave (Hochverfügbarkeit/Hochleistung).

Drupal bietet Unterstützung für eine breite Palette von Datenbanken, wurde aber ursprünglich mit MySQL-Varianten entwickelt. Obwohl die Verwendung von MySQL vollständig unterstützt wird, gibt es bessere Ansätze, die Sie implementieren können. Die Implementierung dieser anderen Ansätze kann jedoch, wenn sie nicht ordnungsgemäß durchgeführt wird, dazu führen, dass Ihre Website große Mengen an Ausfallzeiten erfährt, dass Ihre Anwendung Leistungsprobleme erleidet und dass es zu Schreibproblemen bei Ihren Slaves kommen kann. Die Durchführung von Wartungsarbeiten wäre ebenfalls schwierig, da Sie ein Failover benötigen, um die Server-Upgrades oder -Patches (Hardware oder Software) ohne Ausfallzeiten anzuwenden. Dies gilt insbesondere dann, wenn Sie über große Datenmengen verfügen, die möglicherweise erhebliche Auswirkungen auf Ihr Unternehmen haben.

Das sind Situationen, die Sie nicht wollen, weshalb wir in diesem Blog besprechen, wie Sie Datenbank-Failover für Ihre MySQL- oder PostgreSQL-Datenbanken implementieren können.

Warum benötigt Ihre Drupal-Website ein Datenbank-Failover?

Aus Wikipedia „Failover ist das Umschalten auf einen redundanten oder Standby-Computerserver, ein System, eine Hardwarekomponente oder ein Netzwerk bei einem Ausfall oder einer abnormalen Beendigung der zuvor aktiven Anwendung, des Servers, des Systems, der Hardwarekomponente oder des Netzwerks. Failover und Switchover sind im Wesentlichen die gleichen Vorgänge, außer dass das Failover automatisch erfolgt und normalerweise ohne Vorwarnung funktioniert, während das Switchover einen menschlichen Eingriff erfordert.“

Im Datenbankbetrieb ist Switchover auch ein Begriff, der für manuelles Failover verwendet wird, was bedeutet, dass eine Person erforderlich ist, um das Failover durchzuführen. Failover ist praktisch für jeden Administrator, da es unerwünschte Probleme wie versehentliches Löschen/Verwerfen von Tabellen, lange Ausfallzeiten mit Auswirkungen auf das Geschäft, Datenbankbeschädigung oder Beschädigung auf Systemebene isoliert.

Datenbank-Failover besteht aus mehr als einem einzelnen Datenbankknoten, entweder physisch oder virtuell. Da ein Failover erfordert, dass Sie zu einem anderen Knoten wechseln, können Sie im Idealfall auch zu einem anderen Datenbankserver wechseln, wenn ein Host mehrere Datenbankinstanzen auf einem einzigen Host ausführt. Das kann immer noch Switchover oder Failover sein, aber normalerweise geht es eher um Redundanz und Hochverfügbarkeit, falls auf dem aktuellen Host eine Katastrophe eintritt.

MySQL-Failover für Drupal

Die Durchführung eines Failovers für Ihre Drupal-basierte Anwendung erfordert, dass die von der Datenbank verarbeiteten Daten weder unterschieden noch getrennt werden. Es stehen mehrere Lösungen zur Verfügung, und wir haben einige davon bereits in früheren Multiplenines-Blogs besprochen. Vielleicht möchten Sie unsere Einführung in Failover für die MySQL-Replikation lesen – den 101-Blog.

Die Master-Slave-Umschaltung

Die gebräuchlichsten Ansätze für MySQL Failover sind die Master-Slave-Umschaltung oder das manuelle Failover. Hier gibt es zwei Möglichkeiten:

  • Sie können Ihre Datenbank mit einer typischen asynchronen Master-Slave-Replikation implementieren.
  • oder kann mit asynchroner Master-Slave-Replikation unter Verwendung von GTID-basierter Replikation implementiert werden.

Der Wechsel zu einem anderen Master könnte schneller und einfacher sein. Dies kann mit der folgenden MySQL-Syntax erfolgen:

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

oder mit GTID können Sie einfach tun,

...

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

...

Wit

Die Verwendung des Nicht-GTID-Ansatzes erfordert, dass Sie zuerst die Protokolldatei und die Protokollposition des Masters bestimmen. Sie können dies feststellen, indem Sie sich den Status des Masters im Master-Knoten ansehen, bevor Sie umschalten. 

mysql> MASTER STATUS;

Sie können auch erwägen, Ihren Server zu härten, indem Sie sync_binlog =1 und innodb_flush_log_at_trx_commit =1 hinzufügen, da Sie im Falle eines Absturzes Ihres Masters eine höhere Wahrscheinlichkeit haben, dass Transaktionen vom Master nicht mit Ihrem Slave synchronisiert sind ( s). In einem solchen Fall hat der beförderte Master eine höhere Chance, ein konsistenter Datenquellenknoten zu sein.

Dies ist jedoch möglicherweise nicht der beste Ansatz für Ihre Drupal-Datenbank, da dies zu langen Ausfallzeiten führen kann, wenn es nicht korrekt ausgeführt wird, z. B. wenn es abrupt heruntergefahren wird. Wenn in Ihrem Master-Datenbankknoten ein Fehler auftritt, der zum Absturz einer Datenbank führt, muss Ihre Anwendung auf eine andere Datenbank verweisen, die als Ihr neuer Master auf Standby wartet, oder indem Sie Ihren Slave zum Master befördern. Sie müssen genau angeben, welcher Knoten übernehmen soll, und dann die Verzögerung und Konsistenz dieses Knotens bestimmen. Dies zu erreichen ist nicht so einfach wie SET GLOBAL read_only=1; CHANGE MASTER TO… (usw.), es gibt bestimmte Situationen, die eine tiefere Analyse erfordern, indem man sich die realisierbaren Transaktionen ansieht, die auf diesem Standby-Server oder beförderten Master vorhanden sein müssen, um dies zu erreichen.

Drupal-Failover mit MHA

Eines der gängigsten Tools für automatisches und manuelles Failover ist MHA. Es gibt es schon seit langer Zeit und wird immer noch von vielen Organisationen verwendet. Sie können sich diese früheren Blogs zu den Themen Top Common Issues with MHA and How to Fix Them oder MySQL High Availability Tools – Comparing MHA, MRM and ClusterControl ansehen.

Drupal-Failover mit Orchestrator

Orchestrator ist inzwischen weit verbreitet und wird von großen Organisationen wie Github und Booking.com verwendet. Sie können damit nicht nur ein Failover verwalten, sondern auch Topologieverwaltung, Hosterkennung, Refactoring und Wiederherstellung. Es gibt hier einen netten externen Blog, den ich sehr nützlich fand, um mehr über seinen Failover-Mechanismus mit Orchestrator zu erfahren. Es ist eine zweiteilige Blogserie; Teil eins und Teil zwei.

Drupal-Failover mit MaxScale

MaxScale ist nicht nur ein Load Balancer, der für MariaDB-Server entwickelt wurde, es erweitert auch die Hochverfügbarkeit, Skalierbarkeit und Sicherheit für MariaDB und vereinfacht gleichzeitig die Anwendungsentwicklung, indem es von der zugrunde liegenden Datenbankinfrastruktur entkoppelt wird. Wenn Sie MariaDB verwenden, könnte MaxScale eine relevante Technologie für Sie sein. Sehen Sie sich unsere vorherigen Blogs an, um zu erfahren, wie Sie den MaxScale-Failover-Mechanismus verwenden können.

Drupal-Failover mit ClusterControl

ClusterControl von Severalnines bietet ein breites Spektrum an Datenbankverwaltungs- und Überwachungslösungen. Ein Teil der von uns angebotenen Lösungen ist automatisches Failover, manuelles Failover und Cluster-/Knotenwiederherstellung. Dies ist sehr hilfreich, da es als Ihr virtueller Datenbankadministrator fungiert und Sie in Echtzeit benachrichtigt, falls sich Ihr Cluster im „Panikmodus“ befindet, während die Wiederherstellung vom System verwaltet wird. In diesem Blog How to Automate Database Failover with ClusterControl erfahren Sie mehr über das ClusterControl-Failover.

Andere MySQL-Lösungen

Einige der alten Ansätze sind immer noch anwendbar, wenn Sie ein Failover durchführen möchten. Es gibt MMM, MRM, oder Sie können Group Replication oder Galera auschecken (Hinweis:Galera verwendet keine asynchrone, sondern eine synchrone Replikation). Failover in einem Galera-Cluster funktioniert nicht wie bei der asynchronen Replikation. Mit Galera können Sie einfach auf einen beliebigen Knoten schreiben oder, wenn Sie einen Master-Slave-Ansatz implementieren, Ihre Anwendung an einen anderen Knoten leiten, der der aktive Schreiber für den Cluster sein wird.

Drupal-PostgreSQL-Failover

Da Drupal PostgreSQL unterstützt, werden wir auch die Tools zur Implementierung eines Failover- oder Switchover-Prozesses für PostgreSQL testen. PostgreSQL verwendet die integrierte Streaming-Replikation, Sie können sie jedoch auch so einstellen, dass sie eine logische Replikation verwendet (in Version 10 als Kernelement von PostgreSQL hinzugefügt).

Drupal-Failover mit pg_ctlcluster

Wenn Ihre Umgebung Ubuntu ist, ist die Verwendung von pg_ctlcluster eine einfache und einfache Möglichkeit, ein Failover zu erreichen. Sie können zum Beispiel einfach den folgenden Befehl ausführen:

$ pg_ctlcluster 9.6 pg_7653 promote

oder mit RHEL/Centos können Sie den pg_ctl-Befehl genauso verwenden,

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

server promoting

Sie können auch ein Failover eines Protokollversand-Standby-Servers auslösen, indem Sie eine Auslöserdatei mit dem Dateinamen und dem Pfad erstellen, die durch trigger_file in der recovery.conf angegeben werden.

Sie müssen hier mit Standby-Promotion oder Slave-Promotion vorsichtig sein, da Sie möglicherweise sicherstellen müssen, dass nur ein Master die Lese-Schreib-Anfrage akzeptiert. Das bedeutet, dass Sie während der Umschaltung möglicherweise sicherstellen müssen, dass der vorherige Master gelockert oder gestoppt wurde.

Umschaltung oder manuelles Failover vom Primär- auf den Standby-Server zu erledigen, kann schnell gehen, aber es erfordert einige Zeit, den Failover-Cluster neu vorzubereiten. Das regelmäßige Umschalten von primär auf Standby ist eine nützliche Praxis, da es regelmäßige Ausfallzeiten auf jedem System zu Wartungszwecken ermöglicht. Dies dient auch als Test des Failover-Mechanismus, um sicherzustellen, dass er wirklich funktioniert, wenn Sie ihn brauchen. Schriftliche Verwaltungsverfahren werden immer empfohlen.

Automatisches Drupal-PostgreSQL-Failover

Anstelle eines manuellen Ansatzes benötigen Sie möglicherweise ein automatisches Failover. Dies ist insbesondere dann erforderlich, wenn ein Server aufgrund eines Hardwarefehlers oder einer Beschädigung der virtuellen Maschine ausfällt. Möglicherweise benötigen Sie auch eine Anwendung, die das Failover automatisch durchführt, um die Ausfallzeit Ihrer Drupal-Anwendung zu verringern. Wir werden nun einige dieser Tools durchgehen, die für automatisches Failover verwendet werden können.

Drupal-Failover mit Patroni

Patroni ist eine Vorlage, mit der Sie Ihre eigene angepasste Hochverfügbarkeitslösung mit Python und – für maximale Zugänglichkeit – einem verteilten Konfigurationsspeicher wie ZooKeeper, etcd, Consul oder Kubernetes erstellen können. Datenbankingenieure, DBAs, DevOps-Ingenieure und SREs, die HA PostgreSQL schnell im Rechenzentrum – oder anderswo – bereitstellen möchten, werden es hoffentlich nützlich finden

Drupal-Failover mit Pgpool

Pgpool-II ist eine Proxy-Software, die sich zwischen den PostgreSQL-Servern und einem PostgreSQL-Datenbankclient befindet. Abgesehen von einem automatischen Failover verfügt es über mehrere Funktionen, darunter Verbindungspooling, Lastausgleich, Replikation und Begrenzung der überschüssigen Verbindungen. Sie können mehr über dieses Tool in unserem dreiteiligen Blog lesen; Teil eins, Teil zwei, Teil drei.

Drupal-Failover mit pglookout

pglookout ist ein PostgreSQL-Replikationsüberwachungs- und Failover-Daemon. pglookout überwacht die Datenbankknoten, ihren Replikationsstatus und handelt entsprechend diesem Status. Beispielsweise das Aufrufen eines vordefinierten Failover-Befehls, um einen neuen Master hochzustufen, falls der vorherige verloren geht.

pglookout unterstützt zwei verschiedene Knotentypen, solche, die auf den Datenbankknoten selbst installiert werden, und Beobachterknoten, die überall installiert werden können. Der Zweck von pglookout auf den PostgreSQL-DB-Knoten besteht darin, den Replikationsstatus des Clusters zu überwachen und entsprechend zu handeln. Die Beobachter haben einen eingeschränkteren Aufgabenbereich:Sie beobachten lediglich den Clusterstatus, um einen anderen Blickwinkel auf den Clusterstatus zu geben.

Drupal-Failover mit repmgr

repmgr ist eine Open-Source-Tool-Suite zur Verwaltung von Replikation und Failover in einem Cluster von PostgreSQL-Servern. Es erweitert die integrierten Hot-Standby-Funktionen von PostgreSQL um Tools zum Einrichten von Standby-Servern, Überwachen der Replikation und Durchführen von Verwaltungsaufgaben wie Failover oder manuellen Switchover-Vorgängen.

repmgr bietet erweiterte Unterstützung für die integrierten Replikationsmechanismen von PostgreSQL, seit sie in Version 9.0 eingeführt wurden. Die aktuelle repmgr-Serie, repmgr 4, unterstützt die neuesten Entwicklungen in der Replikationsfunktionalität, die von PostgreSQL 9.3 eingeführt wurden, wie z. B. kaskadierende Replikation, Zeitachsenwechsel und Basissicherungen über das Replikationsprotokoll.

Drupal-Failover mit ClusterControl

ClusterControl unterstützt automatisches Failover für PostgreSQL. Wenn Sie einen Vorfall haben, kann Ihr Sklave automatisch zum Master-Status befördert werden. Mit ClusterControl können Sie auch eigenständige, replizierte oder geclusterte PostgreSQL-Datenbanken bereitstellen. Sie können einen Knoten auch ganz einfach mit einer einzigen Aktion hinzufügen oder entfernen.

Andere PostgreSQL-Drupal-Failover-Lösungen

Es gibt sicherlich automatische Failover-Lösungen, die ich in diesem Blog vielleicht übersehen habe. Wenn ja, fügen Sie bitte unten Ihre Kommentare hinzu, damit wir Ihre Gedanken und Erfahrungen mit Ihrer Implementierung und Einrichtung für Failover erfahren können, insbesondere für Drupal-Websites oder -Anwendungen.

Zusätzliche Lösungen für Drupal-Failover

Während die Tools, die ich zuvor erwähnt habe, definitiv die Lösung für Ihre Probleme mit dem Failover handhaben, kann das Hinzufügen einiger Tools, die das Failover ziemlich einfacher und sicherer machen und eine vollständige Isolierung zwischen Ihrer Datenbankebene haben, zufriedenstellend sein.

Drupal-Failover mit ProxySQL

Mit ProxySQL können Sie Ihre Drupal-Websites oder -Anwendungen einfach auf den ProxySQL-Serverhost verweisen und dieser bestimmt, welcher Knoten Schreibvorgänge und welche Knoten Lesevorgänge erhalten. Die Magie geschieht transparent innerhalb der TCP-Schicht und es sind keine Änderungen an Ihrer Anwendungs-/Website-Konfiguration erforderlich. Darüber hinaus fungiert ProxySQL auch als Ihr Load Balancer für Ihre Schreib- und Leseanforderungen für Ihren Datenbankverkehr. Dies gilt nur, wenn Sie MySQL-Datenbankvarianten verwenden.

Drupal-Failover mit HAProxy mit Keepalived

Die Verwendung von HAProxy und Keepalived fügt Ihrer Drupal-Datenbank mehr Hochverfügbarkeit und Redundanz hinzu. Wenn Sie ein Failover durchführen möchten, kann dies erfolgen, ohne dass Ihre Anwendung weiß, was in Ihrer Datenbankschicht vor sich geht. Richten Sie Ihre Anwendung einfach auf die vrrp-IP, die Sie in Ihrem Keepalived eingerichtet haben, und alles wird vollständig von Ihrer Anwendung isoliert behandelt. Ein automatisches Failover wird von Ihrer Anwendung transparent und unwissentlich gehandhabt, sodass keine Änderungen vorgenommen werden müssen, wenn beispielsweise ein Notfall aufgetreten ist und eine Wiederherstellung oder ein Failover angewendet wurde. Das Gute an diesem Setup ist, dass es sowohl für MySQL- als auch für PostgreSQL-Datenbanken anwendbar ist. Ich schlage vor, dass Sie sich unseren Blog PostgreSQL Load Balancing Using HAProxy &Keepalived ansehen, um mehr darüber zu erfahren, wie das geht.

Alle oben genannten Optionen werden von ClusterControl unterstützt. Sie können die Datenbank bereitstellen oder importieren und dann ProxySQL, MaxScale oder HAProxy &Keepalived bereitstellen. Alles wird verwaltet, überwacht und automatisch eingerichtet, ohne dass eine weitere Konfiguration Ihrerseits erforderlich ist. Das alles läuft im Hintergrund ab und erzeugt automatisch ein produktionsreifes Produkt.

Fazit

Eine immer verfügbare Drupal-Website oder -Anwendung zu haben, kann kompliziert zu erstellen sein, insbesondere wenn Sie eine große Menge an Datenverkehr erwarten. Wenn Sie jedoch über die richtigen Tools, das richtige Setup und den richtigen Technologie-Stack verfügen, ist es möglich, eine hohe Verfügbarkeit und Redundanz zu erreichen.

Und wenn nicht? Dann richtet ClusterControl es ein und wartet es für Sie. Alternativ können Sie ein Setup mit den in diesem Blog erwähnten Technologien erstellen, von denen die meisten kostenlose Open-Source-Tools sind, die Ihren Anforderungen entsprechen.