MySQL in Compute Engine konfigurieren

Compute Engine bietet eine Reihe verschiedener Instanztypen und Speicheroptionen zum Lesen und Schreiben von Daten aus Ihren MySQL-Datenbanken. Damit Sie die beste Leistung und die niedrigsten Kosten für Ihre Datenbankarbeitslasten erzielen, empfehlen wir, neuere IaaS-Produkte (Infrastructure-as-a-Service) zu verwenden.

Die folgenden Konfigurationsempfehlungen berücksichtigen, dass MySQL-Arbeitslasten häufig in leselastigen Systemen wie der Online-Transaktionsverarbeitung (OLTP) oder der Datenbank, die einer typischen Webanwendung zugrunde liegt, verwendet werden. Sie berücksichtigen auch gängige Konfigurationsoptionen wie die Verwendung von MySQL 8.0 oder höher und die Verwendung der InnoDB-Speicher-Engine. Bei leistungsintensiven Arbeitslasten müssen Sie möglicherweise Ihre Konfigurationen anpassen. Wir empfehlen, diese Anleitung als Ausgangspunkt für die Bereitstellung zu verwenden und dann mit Ihrer tatsächlichen Arbeitslast zu testen, um zu prüfen, ob Ihre Konfiguration Ihren Anforderungen entspricht.

Virtuelle Maschine (VM) auswählen

Für MySQL-Arbeitslasten empfehlen wir die Verwendung der neuesten Generation von C- und N-Maschinenfamilien, da sie Formen umfassen, die für die meisten praktischen MySQL-Konfigurationen gut geeignet sind. Eine Einführung in diese Maschinenserien finden Sie im Google Cloud Blogpost. Diese Maschinenfamilien verwenden Titanium und basieren auf Prozessoren der neuesten Generation von Intel, AMD und Axion.

Fokus auf Leistung

Für leistungsintensive Arbeitslasten wie geschäftskritische MySQL-Datenbanken empfehlen wir die neuesten C4- und C4A-Instanzen, sofern sie in Ihrer Region verfügbar sind. Wenn Sie nicht darauf zugreifen können, bieten die Instanzen C3 und C3D eine ähnliche Leistung.

Diese Instanzen bieten die niedrigste und konsistenteste Latenz für rechenintensive Vorgänge und umfassen die folgenden nützlichen Funktionen für leistungsbezogene Arbeitslasten:

Wenn Sie eine C4A-, C3- oder C3D-Instanz verwenden, können Sie auch lokale SSDs verwenden, um bestimmte Leistungsanforderungen zu erfüllen.

Kosten optimieren

Für Arbeitslasten, bei denen die Kostenoptimierung oberste Priorität hat, z. B. MySQL-Datenbanken mit geringem bis mittlerem Traffic oder Datenbanken, die in Test- oder Entwicklungsumgebungen verwendet werden, empfehlen wir die Verwendung der neuesten N4-Instanzen. Diese Instanzen verwenden die nächste Generation der dynamischen Ressourcenverwaltung von Compute Engine, um Ihre Gesamtkosten zu optimieren und gleichzeitig eine solide Leistung zu erzielen. Sie bieten jedoch nicht die starken Garantien von C4-, C4A-, C3- und C3D-Instanzen. Weitere Informationen finden Sie unter Dynamische Ressourcenverwaltung der nächsten Generation.

Größe der VM konfigurieren

Für jede VM, die Sie verwenden, ist es wichtig, die richtige VM-Größe für die gewünschte MySQL-Leistung auszuwählen.

Wenn Sie eine hohe Leistung bei Schreibtransaktionen pro Sekunde (TPS) anstreben, ist der wichtigste Faktor der Blockspeicher. Weitere Informationen finden Sie unten auf dieser Seite unter Blockspeicher konfigurieren.

Wenn Sie eine hohe Leistung bei Leseabfragen pro Sekunde (QPS) anstreben, empfehlen wir dringend, den RAM-basierten Pufferpool von MySQL zu verwenden, um häufig verwendete Daten im Cache zu speichern und Festplattenzugriffe zu reduzieren. Um diese Vorteile zu maximieren, führen Sie die folgenden Schritte aus:

  • Wählen Sie eine VM-Größe aus, die dafür sorgt, dass der Arbeitssatz oder die Gesamtmenge an Daten, die Ihre Datenbank gleichzeitig verarbeitet, in den Pufferpool passt.
  • Legen Sie die Größe des Pufferpools so fest, dass der größte Teil des RAM auf der VM verwendet wird.

Um die Kosten für die Dimensionierung Ihrer VM auf diese Weise zu minimieren, empfehlen wir, eine VM mit einem hohen Verhältnis von RAM zu virtuellen CPUs (vCPUs) zu verwenden, damit Sie nicht für vCPUs bezahlen, die Sie nicht nutzen.

Um für die meisten MySQL-Arbeitslasten ein ideales Gleichgewicht zu erzielen, ermitteln Sie die Arbeitsmenge Ihrer Arbeitslast und wählen Sie dann die kleinste highmem-Instanzkonfiguration aus, die diese Arbeitsmenge im RAM aufnehmen kann. highmem-Instanzkonfigurationen haben etwa 8 GB RAM pro vCPU. So haben Sie genügend Arbeitsspeicher, um eine große Arbeitsmenge zu cachen, und gleichzeitig genügend CPU, um eine hohe Abfragelast zu bewältigen.

Bei Arbeitslasten mit großen Arbeitsmengen, aber niedrigen Abfrageraten können Sie die Gesamtkosten mit N4-Instanzen weiter optimieren, indem Sie benutzerdefinierte Maschinentypen mit erweitertem Arbeitsspeicher verwenden, um das Verhältnis von RAM zu vCPU weiter zu erhöhen.

Netzwerkbandbreite der VM konfigurieren

In den meisten MySQL-Anwendungsfällen können Sie die Standardlimits für die Netzwerkbandbreite für Ihre Instanz beibehalten. Wenn das für Sie in Ordnung ist, müssen Sie nicht auf Tier_1-Netzwerk umstellen.

Blockspeicher konfigurieren

Google Cloud Hyperdisk ist die einzige Generation von dauerhaftem Blockspeicher, die für aktuelle Compute Engine-VM-Familien verfügbar ist. Wir sind davon überzeugt, dass Hyperdisk Balanced für die meisten MySQL-Arbeitslasten am besten geeignet ist. Weitere Informationen zu Hyperdisk finden Sie in der Hyperdisk-Dokumentation.

Google Cloud-Hyperdisk

Hyperdisk Balanced bietet die folgenden Funktionen:

  • SSD-Latenz (Solid State Drive) zu niedrigen Kosten
  • Hochleistungskonfigurationen für Anwendungen, die sie benötigen
  • Besser als 99,999% Langlebigkeit, um vor dem branchenweiten Risiko von Hardwareausfällen und stillen Datenbeschädigungen zu schützen
  • Verschlüsselung aller Hyperdisk-Daten bei Inaktivität mit von Google verwalteten oder vom Kunden verwalteten Verschlüsselungsschlüsseln

Leistungsniveau auswählen

Bei Hyperdisk Balanced wählen Sie die Leistungsstufe unabhängig von der Speichergröße für das Laufwerk aus. So können Sie die Leistung Ihrer Datenbank optimieren und zahlen nur für die E/A-Ressourcen, die für Ihre Arbeitslast erforderlich sind. Wenn der Pufferpool einer MySQL-Datenbank größer als ihr Arbeitsset ist, können während des Steady-State-Betriebs fast alle Leseanfragen aus dem Pufferpool bedient werden, ohne dass auf das Laufwerk zugegriffen werden muss.

Berücksichtigen Sie die MySQL-Schreibarbeitslast, insbesondere die folgenden Aspekte, um ein Leistungsniveau für Ihr Hyperdisk-Volume auszuwählen:

  • Zugriff auf InnoDB-Wiederholungsprotokolle
  • Nachfolgende Aktualisierungen von InnoDB-Datendateien und ‑Indizes

Außerhalb des normalen Betriebs können auch Datenbankwartungsereignisse zu einer unregelmäßigen Festplattenleistung führen. Die Häufigkeit, mit der dies geschieht, hängt in der Regel von der Schreiblast Ihrer Datenbank ab. Daher ist es wahrscheinlicher in Situationen wie der Wiederherstellung nach einem Absturz mit Redo-Logs oder einem Sicherungssystem, das sich selbst kopiert, indem es alle Datenbankänderungen seit der letzten Sicherung liest.

Laufwerkgröße festlegen

Es gibt drei gängige Strategien zum Festlegen der Grenzwerte für die Laufwerksleistung:

  1. Standardkonfiguration verwenden Jedes Laufwerk bietet mindestens 3.000 Eingabe-/Ausgabeoperationen pro Sekunde (IOPS) und einen Durchsatz von 140 MiB/s. Dies reicht für einfache MySQL-Arbeitslasten und Bootvolumes des Betriebssystems aus. Wenn Ihr Anwendungsfall diese Grenzen überschreitet, können Sie die bereitgestellte E/A-Leistung bei Bedarf ändern, ohne Ihre Arbeitslast zu stoppen.
  2. Vorhandene Nutzung messen: Wenn Ihre Datenbank bereits in einer anderen Umgebung ausgeführt wird, erfassen Sie die IOPS und den Durchsatz der Festplatte mit einer Granularität von einer Minute oder weniger. Nachdem Sie ein bis zwei Wochen lang Daten gesammelt haben, sodass Ihr Datensatz einige Schwankungen bei der Last und normale Wartungsereignisse enthält, wählen Sie einen Wert mit hohem Perzentil aus diesem Datensatz aus und fügen Sie einen kleinen Puffer hinzu, um organisches Wachstum oder unerwartete Nutzung zu berücksichtigen.
  3. Schätzen Sie Ihren Bedarf und passen Sie ihn später an. Wenn Sie keine vorhandene Datenquelle haben, müssen Sie Ihre Leistungsanforderungen möglicherweise zuerst schätzen und dann nach der Bereitstellung weiter optimieren. Wir empfehlen, einen höheren Wert als ursprünglich benötigt bereitzustellen, damit es bei Ihrer Arbeitslast nicht zu Leistungsengpässen kommt. Anschließend können Sie die bereitgestellte Leistung an Ihre Arbeitslast anpassen.

Festplattenleistung steigern

Sie können die Leistung jedes Hyperdisk Balanced-Laufwerks auf maximal 160.000 IOPS und 2.400 MB/s Durchsatz steigern. Die Größe Ihrer VM bestimmt die maximalen Leistungslimits von Hyperdisk. Wenn Sie also eine sehr hohe Hyperdisk-Leistung benötigen, müssen Sie möglicherweise die Anzahl der Kerne Ihrer VM erhöhen. Wenn Ihre anspruchsvollsten Arbeitslasten eine höhere Laufwerksleistung erfordern, als ein einzelnes Hyperdisk Balanced-Laufwerk bieten kann, können Sie mehrere Hyperdisk Balanced-Laufwerke mit einer der folgenden Methoden zusammenfassen:

  • Upgrade auf Hyperdisk Extreme
  • Verwenden Sie einen anderen Software-RAID-Mechanismus (Redundant Array of Independent Disks), z. B. mdadm.

Wenn Sie Ihre MySQL-Datenbanken skalieren, können Sie die Kapazität und Leistung Ihrer Festplatten dynamisch und ohne Ausfallzeiten erhöhen. Dies trägt zur Leistungssteigerung von OLAP-Arbeitslasten (Online Analytical Processing) bei, die große komplexe Joins ausführen, die nicht in den RAM passen und auf die Festplatte ausgelagert werden. In seltenen Fällen können MySQL-Arbeitslasten, die eine extrem niedrige Speicherlatenz erfordern und Datenverlust tolerieren können, ihren gesamten Datensatz auf einer lokalen SSD speichern. Sie können auch die folgenden Hybridlösungen verwenden, um die Leselatenz zu verbessern und die Verringerung der Langlebigkeit zu begrenzen:

  • Spiegeln Sie Ihr Dataset zwischen einer Hyperdisk und einer lokalen SSD.
  • Verwenden Sie einen Volume Manager, um die lokale SSD als Cache für Daten zu konfigurieren, die auf einer zugrunde liegenden Hyperdisk gespeichert sind.

Zusätzliche Hyperdisk-Funktionen nutzen

Hyperdisk bietet außerdem die folgenden Funktionen, die Workflows für Hochverfügbarkeit und Notfallwiederherstellung vor Ort ergänzen oder vereinfachen können:

Weitere Informationen zum Konfigurieren dieser Funktionen mit MySQL für Compute Engine finden Sie im Abschnitt Hochverfügbarkeit weiter unten auf dieser Seite.

Lokale SSDs

Bei einigen Compute Engine-Maschinenfamilien können Sie lokale SSDs anstelle von Hyperdisk verwenden. Dies ist kein dauerhafter Speicher, aber MySQL-Arbeitslasten verwenden ihn häufig zum Speichern von temporären Tablespaces.

Informationen zur Verwendung lokaler SSDs zum Skalieren von MySQL-Datenbanken finden Sie auf dieser Seite unter Dynamische Größenanpassung von Laufwerken.

Zusätzliche Compute Engine-Funktionen

Mit den folgenden Compute Engine-Funktionen können Sie Ihre MySQL-Bereitstellung optimieren.

Cloud Monitoring

Verwenden Sie dieGoogle Cloud console, um die Leistung Ihrer VM und die Nutzung von Infrastrukturdiensten zu überwachen. Auf der Seite VM-Instanzen können Sie auf dem Tab Beobachtbarkeit leistungsbezogene Messwerte wie CPU- und Arbeitsspeicherauslastung, Netzwerkbandbreite und bereitgestellte Leistung Ihrer Instanzen überwachen. Auf der Seite Laufwerke können Sie auf dem Tab Beobachtbarkeit den Durchsatz und die IOPS Ihrer Laufwerk-Volumes überwachen.

Wenn Sie die angezeigten Leistungsmesswerte anpassen möchten, verwenden Sie Cloud Monitoring, um Abfragen zu erstellen. Sie können die Leistungsmesswerte auswählen, die Sie für Ihre Infrastrukturdienste sehen möchten. Für MySQL-spezifische Messwerte bietet Compute Engine ein Plug-in für MySQL-Arbeitslasten.

Best Practices für die Konfiguration Ihres Betriebssystems

  • Verwenden Sie ein geeignetes Dateisystem. Google konzentriert sich auf die Optimierung für die ext4- und XFS-Dateisysteme von Linux. Die meisten Dateisysteme eignen sich jedoch für die Verwendung mit MySQL.
  • Deaktivieren Sie „Transparent Huge Pages“ (THP) in der Konfiguration Ihres Basisbetriebssystems. Eine Anleitung zum Deaktivieren von THP finden Sie in der THP-Dokumentation.
  • Wenn Sie Linux verwenden, nutzen Sie die Flags relatime und lazytime für die Konfiguration der Dateisystembereitstellung. Dadurch wird der Leistungsaufwand reduziert, der mit dem Aktualisieren der Werte atime, mtime und ctime für Dateien verbunden ist, wenn sie gelesen oder geändert werden oder sich ihre Metadaten ändern.

Best Practices für die Konfiguration von MySQL

Wir empfehlen, die folgenden Konfigurationseinstellungen für MySQL zu verwenden.

  • Aktuelle Version von MySQL verwenden: Google konzentriert sich auf die Optimierung für MySQL-Version 8.0 und höher.

  • Größe des Zwischenspeicherpools erhöhen: MySQL verwendet den Pufferpool, um die Leseleistung zu verbessern, indem Daten im RAM zwischengespeichert werden. Dadurch werden Festplattenzugriffe reduziert. Die Standardgröße des MySQL-Pufferpools beträgt 128 MiB. Das ist für die meisten praktischen Anwendungsfälle zu klein. Wir empfehlen, die Größe von innodb_buffer_pool_size so zu erhöhen, dass sie größer ist als die Größe des Arbeitssatzes, auf den Ihre Anwendung in der Datenbank zugreift. Dies umfasst in der Regel die folgenden Schritte:

    1. Messen oder schätzen Sie die Größe Ihres Arbeitssatzes in einer laufenden Kopie Ihrer MySQL-Instanz.
    2. Wählen Sie eine Größe und Konfiguration der virtuellen Maschine (VM) mit ausreichend RAM für das Arbeitsset aus.
    3. Konfigurieren Sie die Größe des Pufferpools auf der VM so, dass er den Großteil des verfügbaren RAM belegt.

  • Doublewrite-Puffer aktivieren: MySQL verfügt über einen Doublewrite-Puffer, der vor unvollständigen Schreibvorgängen schützt.Dies ist ein Fehlermodus, bei dem ein Schreibvorgang, der mehrere Blöcke auf der Festplatte umfasst, möglicherweise nur teilweise ausgeführt wird, wenn während des Schreibvorgangs ein Hardware- oder Stromausfall auftritt. Um von diesem Schutz zu profitieren, aktivieren Sie innodb_doublewrite.

  • Setzen Sie den Wert von innodb_flush_log_at_trx_commit auf 1. Dadurch wird sichergestellt, dass Schreibtransaktionen auf dem Laufwerk dauerhaft sind, wenn sie committet werden.

  • Um den Leistungsaufwand zu reduzieren, geben Sie einen Wert für innodb_flush_method an. Legen Sie für MySQL-Version 8.0.14 und höher den Wert von innodb_flush_method auf O_DIRECT_NO_FSYNC fest. Dieser Wert ist optimal, aber nur in diesen Versionen vorhanden. Legen Sie für MySQL-Versionen vor 8.0.14 den Wert von innodb_flush_method auf O_DIRECT fest.

  • Legen Sie in Replikationsszenarien mit hoher Verfügbarkeit den Wert von sync_binlog der primären Datenbankinstanz auf 1 fest. MySQL verwendet das binäre Log, um Änderungen von der primären Datenbank an die sekundäre Datenbank zu übertragen. So wird sichergestellt, dass die binären Logs zum Zeitpunkt des Transaktions-Commits mit der geringstmöglichen Replikationsverzögerung und dem geringstmöglichen Recovery Point Objective (RPO) zwischen den Datenbanken committet werden.

  • Wenn Sie MySQL auf Maschinenfamilien der C-Serie verwenden, aktivieren Sie innodb_numa_interleave. So kann der MySQL-Pufferpool die NUMA-Richtlinien (Non-Uniform Memory Access) nutzen.

Wann sollte der Doublewrite-Puffer deaktiviert werden?

Der Doublewrite-Puffer von MySQL, der vor unvollständigen Schreibvorgängen schützt, hat einen Leistungs-Overhead von bis zu 25% für MySQL-Schreibtransaktionen und kann die Transaktionslatenz erhöhen. Google Cloud Hyperdisk bietet integrierten Schutz vor unvollständigen Schreibvorgängen. Wenn Sie MySQL verwenden, um direkt in ein ext4-Dateisystem zu schreiben, das auf Hyperdisk ausgeführt wird, können Sie den Doublewrite-Puffer deaktivieren, sofern Sie Ihr Dateisystem und die Zwischensoftwareschichten richtig konfiguriert haben.

Damit der Schutz vor unvollständigen Schreibvorgängen von Hyperdisk wirksam ist, müssen Sie das Dateisystem und andere Zwischensoftwareschichten zwischen der Datenbank und dem Laufwerk so konfigurieren, dass keine unvollständigen Schreibvorgänge über der Laufwerksebene eingeführt werden. Die folgende Liste enthält Beispiele für Konfigurationen, die oberhalb der Hyperdisk-Ebene zu unvollständigen Schreibvorgängen führen können:

  • Ausführen Ihrer MySQL-Instanz in Containern, einschließlich Google Kubernetes Engine oder selbst gehostetem Kubernetes.
  • Ihre MySQL-Dateien werden in einem XFS-Dateisystem gespeichert, das in den meisten Linux-Kernelkonfigurationen keine ausreichend großen Blockgrößen unterstützt.
  • Speichern Sie Ihre MySQL-Dateien in einer RAID-Konfiguration (Redundant Array of Independent Disks), die Disk Striping verursacht, einschließlich mdadm für Linux oder Storage Spaces und Storage Spaces Direct für Windows.
  • Speichern Sie Ihre MySQL-Dateien auf einem Volume-Manager, z. B. Logical Volume Manager (LVM) für Linux oder Storage Spaces und Storage Spaces Direct für Windows.

  • Speichern Sie Ihre MySQL-Dateien auf Hyperdisk mit einer lokalen SSD, die als Cache konfiguriert ist, und verwenden Sie lvmcache, dm-cache oder bcache für Linux oder Storage Spaces für Windows.

  • Sie führen Ihre MySQL-Instanz in einer VM mit verschachtelter Virtualisierung aus.

Sie können die oben genannten Konfigurationen so einrichten, dass keine unvollständigen Schreibvorgänge auftreten. Wir empfehlen jedoch, den Doublewrite-Puffer nicht zu deaktivieren, da es schwierig ist, zu prüfen, ob eine bestimmte Konfiguration sicher ist.

(Optional) Doublewrite-Puffer deaktivieren

So deaktivieren Sie den Doublewrite-Puffer:

  1. Im ext4-Dateisystem müssen Sie die Funktion bigalloc aktivieren und die Clustergröße des Dateisystems auf 16 KiB oder ein größeres Vielfaches von 16 KiB, das eine Potenz von 2 ist, festlegen. So wird sichergestellt, dass die Schreibvorgänge von MySQL nicht vom Dateisystem in separate E/A-Vorgänge aufgeteilt werden, bevor sie an Hyperdisk gesendet werden. Wenn Sie das Limit nicht erhöhen oder einen Wert kleiner als 16 KiB verwenden, sind Sie nicht vor unvollständigen Schreibvorgängen geschützt. Hier ist ein Beispiel mit einer Clustergröße von 16 KiB, die bei der Erstellung des Dateisystems konfiguriert wird:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Deaktivieren Sie innodb_doublewrite und legen Sie innodb_flush_method auf O_DIRECT oder O_DIRECT_NO_FSYNC fest (je nach Ihrer MySQL-Version, wie oben beschrieben).

Hochverfügbarkeit (HA) und Sicherungslösung konfigurieren

Wir empfehlen dringend, alle wichtigen MySQL-Arbeitslasten durch Konfigurieren von Hochverfügbarkeits- (HA-) und Sicherungslösungen zu schützen. Für Hochverfügbarkeit und Sicherung sind die folgenden Faktoren am wichtigsten:

HA-Lösungen zielen in der Regel auf ein RTO und RPO von nahezu null ab, schützen aber nur vor Infrastrukturausfällen. Backup-Lösungen zielen auf längere RTO- und RPO-Zeiträume ab, bieten aber Schutz für eine größere Anzahl von Ausfallszenarien, z. B.:

  • Versehentliches Löschen von Daten
  • Ransomware-Angriffe
  • Naturkatastrophen

Hochverfügbarkeit konfigurieren

Bei Hochverfügbarkeitsfunktionen werden Speicher- und Rechenredundanz verwendet, um die Ausfallzeiten Ihrer MySQL-Datenbank bei einem Hostausfall oder ‑ausfall zu reduzieren. So können Clientanwendungen auf die Daten zugreifen, auch wenn eine Instanz oder Zone nicht verfügbar ist.

MySQL ermöglicht die Replikation in den folgenden Modi:

  • Asynchroner Modus: Im asynchronen Modus bestätigt die primäre Instanz Schreibtransaktionen, sobald sie lokal committet werden. Wenn es also zu einem Ausfall der primären Instanz kommt, können während des Failovers geringe Mengen an kürzlich geschriebenen Daten verloren gehen, da der RPO-Wert nahe null, aber nicht tatsächlich null ist.
  • Semisynchroner Modus: Im semisynchronen Modus wartet der primäre Knoten mit der Bestätigung der Transaktion, bis eine konfigurierbare Anzahl von Replikaten den Empfang der Transaktion bestätigt hat. Dadurch wird die Wahrscheinlichkeit, dass bei einem ungeplanten Failover kein Datenverlust auftritt, erheblich erhöht, da das RPO effektiv null ist.

In beiden Modi wird die RTO dadurch bestimmt, wie schnell die Systemdiagnosen Folgendes ausführen:

  1. Fehlerhafte Instanz identifizieren
  2. Failover auslösen
  3. Benachrichtigen Sie Clients, dass die Failover-Instanz jetzt die primäre Instanz ist. Verwenden Sie dazu das Domain Name System (DNS) oder eine andere Methode zur Identifizierung des Datenbankservers.

In beiden Replikationsmodi benötigen Sie eine Failover-Instanz, in die repliziert werden kann. Sie können diese Instanz an einem der folgenden Orte finden:

  • Dieselbe Zone, in der sich die primäre Instanz befindet
  • Eine andere Zone in der Region, in der sich die primäre Instanz befindet
  • Eine andere Region als die primäre

Um auch bei zonalen Ausfällen eine hohe Verfügbarkeit aufrechtzuerhalten, empfehlen wir die folgende Konfiguration:

  • Primäre Instanz und Failover-Instanz in verschiedenen Zonen platzieren, unabhängig davon, ob sie sich in derselben Region befinden.
  • Asynchrone Replikation verwenden: Wenn Sie die semisynchrone Replikation verwenden, kann es zu einer hohen Latenz für die Commit-Vorgänge von Schreibtransaktionen kommen, wenn sich die primäre Instanz und die Failover-Instanz in separaten Zonen befinden.
  • Wenn Sie einen RPO von null benötigen, verwenden Sie Hyperdisk Balanced High Availability. Damit können Sie ein Laufwerk synchron über zwei Zonen in derselben Region hinweg replizieren. Weitere Informationen finden Sie im Google-Leitfaden zur Bereitstellung von HA-Diensten mit Hyperdisk High Availability. Wenn Sie Hyperdisk Balanced High Availability konfigurieren, empfehlen wir die Integration mit zustandsorientierten verwalteten Instanzgruppen, um Probleme mit der Instanzintegrität zu diagnostizieren und Wiederherstellungsmaßnahmen zu automatisieren.

Sicherungs- und Datenresilienzplan konfigurieren

Sicherungs- und Datenresilienzpläne helfen, Datenverlust bei Fehlern wie versehentlichem Löschen von Daten, Ransomware-Angriffen und Naturkatastrophen zu verhindern. Sie können sie auch als Kaltarchiv für Compliance- und Prüfungsanforderungen verwenden. Für MySQL gibt es viele Sicherungsmethoden, von denen einige auf Datenbankebene und andere auf Speichervolumeebene ausgeführt werden. Bei der Auswahl einer Methode sollten Sie in erster Linie Ihre RTO- und RPO-Anforderungen berücksichtigen.

Sichern auf Datenbankebene

Für Sicherungen auf Datenbankebene können Sie die folgenden Optionen verwenden, die von MySQL bereitgestellt werden:

  • Inkrementelle Sicherungen auf Grundlage von binärem Logging,bei denen logische Daten-Dumps erstellt werden. Dazu gehören:
  • Tools, die den Sicherungsprozess für Sie verwalten, z. B. MySQL Enterprise Backup.

Weitere Informationen zu den Sicherungsoptionen auf Datenbankebene von MySQL finden Sie in der MySQL-Dokumentation unter Backup and Recovery.

Für alle diese Optionen benötigen Sie ein sekundäres Speichersystem, in das die Sicherungsdaten kopiert werden können. Wir empfehlen die folgenden Tools:

Hyperdisk zum Erstellen von Snapshots und Klonen auf Speicherebene verwenden

Für Sicherungen auf Speicherebene empfehlen wir, Hyperdisk-Produkte zu verwenden, um einen Snapshot, einen Klon oder eine andere Momentaufnahme Ihrer MySQL-Datenbank zu erstellen. Das RPO für diesen Ansatz hängt davon ab, wie oft Sie Snapshots Ihrer Datenbank erstellen. Das RTO hängt davon ab, welche Lösung Sie verwenden.

Wenn eine schnelle Wiederherstellung wichtig ist und Sie nur eine Sicherungsabdeckung innerhalb einer Zone benötigen, empfehlen wir die Verwendung von Instant Snapshots für Hyperdisk. Instant Snapshots erfassen Daten zu einem bestimmten Zeitpunkt inkrementell und können die Daten schnell auf einem neuen Hyperdisk-Volume über Laufwerksklonen wiederherstellen. Dadurch wird ein RTO von wenigen Minuten erreicht. Mit Instant Snapshots können Sie Daten wiederherstellen, wenn der Inhalt eines Laufwerks überschrieben, gelöscht oder beschädigt wurde. Sie sind lokal in derselben Zone oder Region wie das Quelllaufwerk verfügbar. Weitere Informationen finden Sie unter Instant Snapshots.

Für Notfallwiederherstellungsszenarien, in denen Daten mit einer höheren Redundanz als auf dem ursprünglichen Laufwerk und an einem separaten Speicherort gespeichert werden müssen, damit ein einzelner Notfall nicht alle Replikate der Daten beeinträchtigt, empfehlen wir die Verwendung von Archiv- und Standard-Laufwerk-Snapshots von Hyperdisk. Mit Archiv- und Standard-Laufwerk-Snapshots wird eine Kopie der Daten auf dem Laufwerk zu einem bestimmten Zeitpunkt erstellt und in einem unveränderlichen Format mit hoher Redundanz gespeichert. Wenn Sie mehrere Snapshots eines Laufwerks erstellen, z. B. mit einem Snapshot-Zeitplan, werden auf Hyperdisk nur inkrementelle Änderungen gespeichert. Archiv- und Standard-Laufwerk-Snapshots eignen sich gut, wenn Sie einen höheren RTO tolerieren können, da das Kopieren von Daten aus dem Snapshot-Speicher zurück in den VM-Speicher länger dauern kann. Weitere Informationen finden Sie unter Archiv- und Standard-Snapshots für Laufwerke erstellen.

Instant-Snapshots von Hyperdisk sowie Archiv- und Standard-Snapshots sind auf einem einzelnen Laufwerk absturzkonsistent. Wenn Sie also aus einem Snapshot wiederherstellen, muss Ihre MySQL-Datenbank die normalen InnoDB-Wiederherstellungsschritte ausführen, um ihre Protokolle und Datendateien wieder in einen konsistenten Zustand zu versetzen. Je nach Konfiguration des InnoDB-Redo-Logs kann sich der RTO dadurch verlängern. Die folgenden Muster können die Erstellung eines konsistenten Datenbank-Snapshots zusätzlich erschweren:

  • Ihre MySQL-Datenbankdateien sind auf mehrere Volumes verteilt.
  • Sie verwenden Linux-Software-RAID-Dienstprogramme wie mdadm.
  • Sie haben die konfigurierten Speicherorte von MySQL auf Dateisysteme auf verschiedenen Festplatten verteilt.

So erstellen Sie einen Snapshot, der nach dem Wiederherstellen eines Snapshots keine Wiederherstellung erfordert:

  1. Sperren Sie den Schreibzugriff auf die MySQL-Datenbank vorübergehend.
  2. Leeren Sie alle laufenden Puffer auf das Laufwerk mit den Befehlen LOCK INSTANCE FOR BACKUP und FLUSH TABLES WITH READ LOCK.
  3. Snapshot-Vorgänge starten.

  4. Bei Szenarien mit mehreren Festplatten führen Sie nach dem Leeren auf MySQL-Ebene die Befehle sync und fsfreeze auf dem Server aus, um alle laufenden Schreibvorgänge auf die Festplatte zu übertragen und neue eingehende Schreibvorgänge auf Dateisystemebene zu pausieren.

Nachdem Sie den ersten Snapshot Ihrer Datenbank erstellt haben, müssen Sie das Laufwerk nicht mehr sperren, da Hyperdisk die Momentaufnahme schnell erstellt und dann alle nachfolgenden Schritte zum Kopieren des Speichers asynchron verarbeiten kann. Wenn Sie diese Schritte für die Snapshot-Konsistenz benötigen und die Auswirkungen auf die primäre Datenbank entfernen möchten, können Sie die Sicherung auch für ein Datenbankreplikat anstelle der primären Datenbank ausführen.

Nächste Schritte