MySQL Hochverfügbarkeit, Failover und Replikation mit Latenz

Wir sind dabei, ein neues CMS (Drupal 6.x) zu implementieren, das unter MySQL ausgeführt wird. Wir haben zwei Rechenzentren - primäres und sekundäres - mit bekannter Latenz zwischen ihnen. Wir sind uns nicht sicher, welche Version von MySQL wir ausführen werden ... entweder Community oder Enterprise, aber das ist eine TBD. Es sieht so aus, als würden wir die InnoDB-Engine ausführen. Das Betriebssystem wird RedHat EL 5.5 sein. Die primären Server werden aktiv sein, während die sekundären passive oder Hot-Standby-Server sein werden.

Ich möchte Replikation, Hochverfügbarkeit und automatisiertes Failover in MySQL in den beiden Rechenzentren implementieren.

Nach einem Failover auf die sekundären Server möchten wir beim Failback auf die primären Server, dass Daten schnell und vollständig von der sekundären Datenbank zur primären Datenbank synchronisiert werden, damit wir weiterhin Inhalte von den primären Servern bereitstellen können.

Ich bin daran interessiert zu wissen, welche Technologien / Tools / Best Practices verwendet werden können, um diese Probleme zu lösen / anzugehen. Auch Fallstricke oder Ah-Ha-Momente wären sehr willkommen. Ich habe mich über MySQL-Replikation, Clustering und einige Tools von Drittanbietern wie Tungsten und Dolphinics informiert, bin mir aber nicht sicher, wie ich am besten vorgehen soll.

Vielen Dank für Ihre Zeit!

KM

Der Einfachheit halber empfehle ich nur MySQL Circular Replication. Hier ist warum:

Es gibt viele Technologien und Topologien, die MySQL Circular Replication weit überlegen sind. Mein Favorit ist zweifellos DRBD (Distributed Replicated Block Device) . DRBD funktioniert jedoch hervorragend, wenn sich das Serverpaar im selben Gebäude, Rechenzentrum und Rack befindet. Es ist sogar noch besser, wenn Sie ein Crossover-Kabel im Subnetz 192.168.xx zwischen DRBD Primary und DRBD Secondary verwenden. Leider hat DRBD über eine Entfernung zwischen zwei Standorten eine schreckliche Leistung , obwohl DRBD immer noch funktionieren kann. Es gibt keine Netzwerktopologien, die Ihnen die zufriedenstellende DRBD-Leistung bieten, die zwischen zwei Rechenzentren erforderlich ist.

Sobald Sie die MySQL Circular Replication zwischen den beiden DB-Servern in zwei verschiedenen Rechenzentren eingerichtet haben, ist nur noch die Optimierung für das Netzwerk erforderlich. Im Wesentlichen hängt die Replikationsleistung von den Netzwerkeinstellungen (Geschwindigkeit / Latenz der binären Protokollübertragung im MySQL Replication Setup) und der Festplatten-E / A (DRBD) ab.

Eine Alternative, die Sie für eine bessere Redundanz wünschen, ist beispielsweise die folgende:

Einrichten eines DRBD-Paares an beiden Standorten
DRBD-Paar an Standort 1 mit VIP 111.111.111.111
DRBD-Paar an Standort 2 mit VIP 222.222.222.222

Richten Sie die zirkuläre MySQL-Replikation zwischen den DRBD-Primärservern unter folgenden Bedingungen ein:
Verwenden Sie für Standort 1 222.222.222.222 als Master_Host in MySQL.
Für Standort 2 verwenden Sie 111.111.111.111 als Master_Host in MySQL

Obwohl Sie eine gewisse Komplexität einführen, haben Sie jetzt zwei Redundanzstufen: DRBD innerhalb jedes Standorts und MySQL Circular Replication zwischen Standorten. Sie haben die zusätzlichen Vorteile, Backups über mysqldump auf der DRBD-Primärseite des Hot-Standby-Servers auszuführen.

Für das Failover bietet DRBD ein automatisches Failover an einem beliebigen Standort.

Nur für den Fall, dass ein Rechenzentrum überhaupt nicht verfügbar ist, können Sie den DB VIP am Hot-Standby-Standort verwenden.

AKTUALISIEREN

Ich habe gerade eine doppelte Aufnahme gemacht und festgestellt, dass Sie Drupal6 verwenden. Ich bin froh, dass Sie alle Drupal-Tabellen in InnoDB konvertieren werden. Dadurch wird die Möglichkeit von MyISAM-Tabellenaktualisierungen beseitigt, die dazu führen, dass Tabellensperren DB-Verbindungen einfrieren, die lediglich MyISAM-Tabellen lesen. Jedes DML-Update (INSERTs, UPDATEs, DELETEs) für eine MyISAM-Tabelle führt IMMER eine vollständige Tabellensperre durch !!! Durch die Verwendung von InnoDB wird das Sperren auf Zeilenebene eingeführt, wodurch vollständige Tabellensperren vermieden werden.

Darüber hinaus wird DRBD zu Ihrem Freund, wenn alles InnoDB ist, da die Wiederherstellung nach einem Absturz zwischen dem DRBD-Paar konsistent ist. Im Gegensatz dazu kauft DRBD mit MyISAM nichts, da eine abgestürzte MyISAM-Tabelle auf der DRBD-Primärdatenbank einfach auf die DRBD-Sekundärseite dupliziert wird, wie Sie es erraten haben , eine abgestürzte MyISAM-Tabelle.

UPDATE # 2

Sie sollten zwei Redundanzstufen verwenden

Stufe 1: Verwenden Sie in jedem Datenbankzentrum DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html

Richten Sie ein Paar DB-Server ein.
Start DRBD
Startup MySQL auf der DRBD-Primärseite

Dadurch werden redundante Daten auf Festplattenebene erstellt.

Stufe 2: Sie sollten die zirkuläre MySQL-Replikation zwischen
der DRBD-Primärdatenbank von DataCenter 1 und der DRBD-Primärdatenbank von DataCenter 2 einrichten

Auf jeder DRBD-Primärdatenbank wird MySQL ausgeführt und sie fungieren
sowohl als Master als auch als Slave

Ich habe solche Client-Topologien eingerichtet und halte sie für ziemlich stabil.