Skip to main content
Enterprise applications
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

MySQL mit SAN

Beitragende

Es gibt zwei Optionen zur Konfiguration von MySQL mit SAN unter Verwendung des üblichen zwei-Volume-Modells.

Kleinere Datenbanken können auf einem Standard-LUN-Paar platziert werden, sofern die I/O- und Kapazitätsanforderungen innerhalb der Grenzen eines einzigen LUN-Filesystems liegen. Eine Datenbank, die etwa 2.000 zufällige IOPS benötigt, kann beispielsweise auf einem einzelnen Filesystem auf einer einzelnen LUN gehostet werden. In ähnlicher Weise würde eine Datenbank mit einer Größe von nur 100 GB auf eine einzige LUN passen, ohne ein Management-Problem zu verursachen.

Bei größeren Datenbanken sind mehrere LUNs erforderlich. Beispielsweise würde eine Datenbank, die 100.000 IOPS benötigt, höchstwahrscheinlich mindestens acht LUNs benötigen. Eine einzelne LUN würde zu einem Engpass werden, da die Anzahl der SCSI-Kanäle zu Laufwerken nicht ausreicht. Eine 10-TB-Datenbank wäre ähnlich schwierig zu managen auf einer einzigen 10-TB-LUN. Logical Volume Manager sind so konzipiert, die Performance- und Kapazitätsfunktionen mehrerer LUNs miteinander zu verbinden, um Performance und Management zu verbessern.

In beiden Fällen sollte ein Paar ONTAP Volumes ausreichend sein. Bei einer einfachen Konfiguration würde die Datendatei-LUN wie die Protokoll-LUN in ein dediziertes Volume platziert werden. Bei einer logischen Volume Manager-Konfiguration befinden sich alle LUNs in der Datendatei-Volume-Gruppe in einem dedizierten Volume, und die LUNs der Log-Volume-Gruppe befinden sich in einem zweiten dedizierten Volume.

Tipp

NetApp empfiehlt, zwei Dateisysteme für MySQL-Bereitstellungen auf SAN zu verwenden:

  • Das erste Dateisystem speichert alle MySQL-Daten einschließlich Tablespace, Daten und Index.

  • Das zweite Filesystem speichert alle Protokolle (binäre Protokolle, langsame Protokolle und Transaktionsprotokolle).

Es gibt mehrere Gründe für die Trennung von Daten auf diese Weise, unter anderem:

  • Die I/O-Muster von Datendateien und Protokolldateien unterscheiden sich. Eine Trennung würde mehr Optionen mit QoS-Steuerung ermöglichen.

  • Für eine optimale Nutzung der Snapshot Technologie müssen Datendateien unabhängig wiederhergestellt werden können. Das Komminglieren von Datendateien mit Protokolldateien beeinträchtigt die Wiederherstellung von Datendateien.

  • NetApp SnapMirror bietet zwar eine einfache Disaster Recovery-Funktion mit einem geringen RPO für eine Datenbank, erfordert jedoch unterschiedliche Replizierungspläne für die Dateien und Protokolle.
Hinweis Mit diesem grundlegenden Layout für zwei Volumes wird die Lösung zukunftssicher, sodass alle ONTAP Funktionen bei Bedarf genutzt werden können.
Tipp

NetApp empfiehlt das Formatieren Ihres Laufwerks mit dem ext4-Dateisystem aufgrund der folgenden Features:

  • Erweiterter Ansatz für Blockverwaltungsfunktionen, die im Journaling-Dateisystem (JFS) verwendet werden, und verzögerte Zuweisungsfunktionen des erweiterten Dateisystems (XFS).

  • Ext4 erlaubt Dateisysteme mit bis zu 1 Exbibyte (2^60 Bytes) und Dateien mit bis zu 16 Tebibyte (16 * 2^40 Bytes). Im Gegensatz dazu unterstützt das ext3-Dateisystem nur eine maximale Filesystem-Größe von 16 TB und eine maximale Dateigröße von 2 TB.

  • In ext4-Dateisystemen weist die Multiblockzuweisung (mballoc) mehreren Blöcken einer Datei in einem einzigen Vorgang zu, anstatt sie einzeln zuzuweisen, wie in ext3. Diese Konfiguration reduziert den Overhead beim mehrmaligen Aufrufen des Block Allocator und optimiert die Zuweisung von Speicher.

  • Obwohl XFS der Standard für viele Linux-Distributionen ist, verwaltet es Metadaten anders und ist nicht für einige MySQL-Konfigurationen geeignet.
Tipp

NetApp empfiehlt die Verwendung von 4k-Blockgrößenoptionen mit dem mkfs-Dienstprogramm, um die bestehende Block-LUN-Größe auszurichten.

mkfs.ext4 -b 4096

NetApp LUNs speichern Daten in physischen 4-KB-Blöcken, wodurch acht logische 512-Byte-Blöcke entstehen.

Wenn Sie nicht dieselbe Blockgröße einrichten, werden I/O-Vorgänge nicht korrekt an physischen Blöcken ausgerichtet und können in zwei verschiedene Laufwerke in einer RAID-Gruppe geschrieben werden, was zu Latenz führt.

Hinweis Es ist wichtig, dass Sie den I/O so ausrichten, dass reibungslose Lese-/Schreibvorgänge erfolgen. Wenn die I/O jedoch bei einem logischen Block beginnt, der nicht am Anfang eines physischen Blocks liegt, ist die I/O falsch ausgerichtet. I/O-Vorgänge werden nur ausgerichtet, wenn sie an einem logischen Block beginnen – dem ersten logischen Block in einem physischen Block.