MySQL InnoDB über ein Raw-Gerät in einer Aktiv/Passiv-Topologie

Question

Wir haben eine Aktiv/Passiv-Topologie, bei der es zwei x86-Komplexe mit einem gemeinsam genutzten Rohspeicher gibt, wobei nur einer der Knoten zu einem bestimmten Zeitpunkt Zugriff auf den gemeinsam genutzten Speicher hat (auch bekannt als der aktive Knoten).Im Falle eines Failovers im aktiven Knoten initiiert der passive Knoten eine Übernahme und wird zum aktiven Knoten mit Zugriff auf den gemeinsam genutzten Speicher.Jeder Knoten verfügt über einen eigenen Boot-Gerätespeicher mit einem Dateisystem.Auf dem gemeinsam genutzten Speicher darf jedoch kein Dateisystem gemountet sein.

Wir sind daran interessiert, MySQL auf beiden Knoten zu installieren, wobei sich die Daten im gemeinsamen Speicher befinden und nur der aktive Knoten den Server ausführt.

MySQL mit InnoDB kann auf einem Raw-Gerät ausgeführt werden, und es gibt auch eine Anleitung zum Ausführen MySQL über einen Cluster ähnlich unserer Topologie.Im zweiten Beispiel ist jedoch ein Dateisystem im gemeinsam genutzten Speicher gemountet.Das Dateisystemproblem gibt Anlass zu großer Sorge:

ib_logfile* erfordert weiterhin ein Dateisystem.Die Raw-MySQL-Funktion ist also nicht gerade vollständig roh.Bitte korrigieren Sie mich, wenn ich falsch liege.Gibt es eine Problemumgehung, um diese Dateien im Rohspeicher zu speichern?Wir können die Redo-Logs speichern (ib_logfile0, ib_logfile1) im Startgerät des Knotens und löschen Sie diese Dateien immer, bevor der Server startet (damit wir bei mehreren Failovers keine alten Protokolldateien haben).Dies kann jedoch dazu führen, dass eine nicht festgeschriebene Transaktion teilweise festgeschrieben wird, wenn mitten in einer Transaktion ein Fehler auftritt, was der gesamten Idee von Transaktionen widerspricht.

Gibt es weitere Dateien/Funktionen, die das Verhalten von MySQL in dieser Topologie beeinflussen könnten?

Answer 1

Es ist erwähnenswert, dass das Write-Ahead-Protokoll (WAL) von InnoDB, die ib_logfile*, nicht das Einzige ist, das ein Dateisystem benötigt.Du hast:

1. Systemtabellen im MySQL-Schema, die wahrscheinlich die MyISAM-Speicher-Engine verwenden (.frm, .MYD, .MYI pro Tabelle) (die meisten verwenden jetzt InnoDB in 5.7)
2. .frm-Dateien für jede InnoDB-Tabelle, auch wenn der gemeinsam genutzte Systemtabellenbereich verwendet wird (Tabellenmetadaten sind erforderlich)
3. MySQL-Protokolldateien (Fehlerprotokoll, allgemeines Protokoll, Binärprotokoll)
4. SSL-Artefakte
5. auto.cnf (wo die MySQL-Instanz-UUID generiert und automatisch gespeichert wird)
6. db.opt-Datei für jedes Schema (in /<datadir>/<schema>/)
7. .par-Datei, wenn Sie eine partitionierte Tabelle erstellen (in 5.7 nicht mehr vorhanden)
8. .trn- und .trg-Dateien, wenn Sie Trigger erstellen
9. InnoDB tmp-Tablespace (5.6+)
10. Persistierte Pufferpool-Seitenzuordnung (ib_buffer_pool, 5.6+)

Alle oben genannten Punkte liegen typischerweise innerhalb der Datenverzeichnis, also solange du es hast datadir=/some/valid/fs/path -- das wird auch repliziert (z.B.DRBD) oder gemeinsam genutzt (z. B.NFS, GFS, OCFS) zwischen den beiden Knoten – dann ist alles in Ordnung.

Es ist erwähnenswert, dass die Dateien .frm, .par, .trn, .trg und .opt mit dem verschwinden neues Datenwörterbuch.

Seien Sie gespannt auf einige große Ankündigungen in den kommenden Monaten!:) :)

Mir ist nicht klar, warum Sie das RAW-Gerät verwenden?Ich bin mir jedoch sicher, dass Sie Ihre Gründe haben.:) :)

Viel Glück!

Answer 2

Die Rohspeichertechnik eignet sich nur für ibdata1 mit innodb_file_per_table deaktiviert.

Ich habe die Einrichtung bereits ein paar Mal erwähnt

• Jul 25, 2012 : Datenbankdesign – Erstellen mehrerer Datenbanken, um die Probleme mit der Beschränkung der Tabellengröße zu vermeiden
• Feb 26, 2013 : Wartung in MYSQL, wenn innodb_file_per_table deaktiviert ist

Hinweis zur InnoDB-Architektur (Bild von Percona CTO Vadim Tkachenko)

Mit innodb_file_per_table Deaktiviert würden Daten und Indizes für alle InnoDB-Tabellen zusammen mit dem doppelten Schreibpuffer, dem Einfügepuffer, dem Datenwörterbuch, den Rollback-Segmenten und dem Undo-Bereich im Rohspeicher landen.

Im Hinblick auf die Redo-Logs sollten Sie darüber nachdenken, nur ein kleines DRBD-Blockgerät zu verwenden /var/lib/mysql, mit ib_logfile0 Und ib_logfile1 in diesem Ordner.Somit würde das Failover wie folgt ablaufen

• Unterbrechen Sie DRBD zwischen den beiden Servern
• Setzen Sie den DRBD-Status des neuen Servers auf Primary/Unknown
• Mounten Sie DRBD /var/lib/mysql
• Mounten Sie das Rohgerät mit den Informationen von ibdata1
• service mysql start
• DRBD-Geräte synchronisieren
• Aufstellen Schrittmacher/Ukarp Dienste zur Vorbereitung auf das nächste Failover

Ich habe DRBD/ucarp für Failover-Setups bevorzugt. Sehen Sie sich meine alten Beiträge dazu an

UPDATE 2015-10-14 11:30 EDT

Wie ich bereits erwähnt habe, müssen sich die Redo-Logs im DRBD-Blockgerät befinden, auf dem sie gemountet sind /var/lib/mysql.Im Hinblick auf andere wichtige Dateien wie z

• Binärprotokolle
• Relay-Protokolle
• Fehlerprotokoll
• langsames Protokoll
• allgemeines Protokoll

Alle diese Dateien müssen vorhanden sein /var/lib/mysql sowie.Auf diese Weise übertragen Failovers alles, was mit MySQL zu tun hat (abzüglich der Rohdaten, die sich auf der eigenen Festplatte befinden).

WARNUNG :Diese Einrichtung gilt nicht für MyISAM-Tabellen.Wenn ein hartes Failover auftritt, werden alle vor dem Absturz/Failover geöffneten MyISAM-Tabellen als beschädigt markiert und müssen ausgeführt werden REPAIR TABLE auf alle wirken sich auf MyISAM-Tabellen aus.

Wenn alle Ihre Tabellen InnoDB-Tabellen sind, ignorieren Sie diese Warnung.Wenn Sie Ihre verbleibenden MyISAM-Tabellen in InnoDB konvertieren, können Sie diese Warnung ignorieren.(KONVERTIEREN SIE KEINE MyISAM-TABELLEN IN DIE mysql SCHEMA IN InnoDB).