MySQL in Compute Engine konfigurieren

Die Compute Engine bietet eine Reihe verschiedener Instanztypen und Speicheroptionen zum Lesen und Schreiben von Daten aus Ihren MySQL-Datenbanken. Um die beste Leistung und Kosten für Ihre Datenbankarbeitslasten zu erzielen, empfehlen wir die Verwendung von IaaS-Produkten (Infrastructure as a Service) der neuesten Generation.

Bei den folgenden Konfigurationsempfehlungen wird berücksichtigt, dass MySQL-Arbeitslasten häufig in leseintensiven Systemen wie der Online-Transaktionsverarbeitung (OLTP) oder der Datenbank einer typischen Webanwendung verwendet werden. Außerdem werden gängige Konfigurationsoptionen berücksichtigt, z. B. die Verwendung von MySQL Version 8.0 oder höher und die Verwendung der InnoDB-Speicher-Engine. Bei leistungsempfindlichen Arbeitslasten müssen Sie Ihre Konfigurationen möglicherweise anpassen. Wir empfehlen, diesen Leitfaden als Ausgangspunkt für Ihre Bereitstellung zu verwenden und dann mit Ihrer tatsächlichen Arbeitslast zu testen, ob Ihre Konfiguration Ihren Anforderungen entspricht.

Virtuelle Maschine auswählen

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

Konzentrieren Sie sich auf die 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 Leistungsausrichtung.

Diese Instanzen bieten die niedrigste und konstanteste Latenz für rechenintensive Vorgänge und enthalten die folgenden nützlichen Funktionen für leistungsorientierte Arbeitslasten:

  • Hostwartungen mit Vorabankündigung steuern
  • Steuerung der Turbo-Taktfrequenz für einzelne Kerne für eine gleichmäßigere Leistung
  • Tier_1-Netzwerk für eine höhere Netzwerkbandbreite

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

Kosten optimieren

Für Arbeitslasten, bei denen die Kostenoptimierung im Vordergrund steht, z. B. MySQL-Datenbanken mit geringem bis mittlerem Traffic oder Datenbanken, die in Test- oder Entwicklungsumgebungen verwendet werden, empfehlen wir die neuesten N4-Instanzen. Bei diesen Instanzen wird die dynamische Ressourcenverwaltung der nächsten Generation der Compute Engine verwendet, um die Gesamtkosten zu optimieren und gleichzeitig eine solide Leistung zu erzielen. Dabei werden jedoch nicht die strengen Garantien geboten, die C4, C4A, C3 und C3D bieten. 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 Blockspeicher der wichtigste Faktor. Weitere Informationen finden Sie im Abschnitt Blockspeicher konfigurieren weiter unten auf dieser Seite.

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

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

Um die Kosten für die Größenanpassung Ihrer VM so gering wie möglich zu halten, empfehlen wir eine VM mit einem hohen Verhältnis von RAM zu virtuellen CPUs (vCPUs), damit Sie nicht für nicht verwendete vCPUs bezahlen müssen.

Für ein ideales Gleichgewicht bei den meisten MySQL-Arbeitslasten sollten Sie den Arbeitssatz Ihrer Arbeitslast ermitteln und dann die kleinste highmem-Instanzkonfiguration auswählen, die in den Arbeitsspeicher passt. highmem-Instanztypen haben etwa 8 GB RAM pro vCPU. So haben Sie genügend Arbeitsspeicher, um ein großes Arbeitssatz im Cache zu speichern, und gleichzeitig genügend CPU, um eine hohe Abfragelast zu bewältigen.

Bei Arbeitslasten mit großen Arbeitsbereichen, 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

Für die meisten MySQL-Anwendungsfälle können Sie die Standardlimits für die Netzwerkbandbreite Ihrer Instanz beibehalten. Wenn das für Ihre Anforderungen ausreicht, müssen Sie nicht auf Tier_1-Netzwerktechnologie umstellen.

Blockspeicher konfigurieren

Google Cloud Hyperdisk ist die einzige Generation von langlebigem Blockspeicher, die für aktuelle Compute Engine-VM-Familien verfügbar ist. Wir sind der Meinung, 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 zu niedrigen Kosten
  • Hochleistungskonfigurationen für Anwendungen, die sie benötigen
  • Eine Lebensdauer von über 99,999% zum Schutz vor dem branchenweiten Risiko von Hardwareausfällen und unbemerkten Datenbeschädigungen
  • Verschlüsselung aller inaktiven Hyperdisk-Daten mit von Google verwalteten oder vom Kunden verwalteten Verschlüsselungsschlüsseln

Leistungsstufe auswählen

Bei Hyperdisk Balanced wählen Sie das Leistungsniveau unabhängig von der Speichergröße für das Laufwerk aus. So können Sie die Leistung Ihrer Datenbank optimieren und gleichzeitig nur für die E/A-Ressourcen (Eingabe/Ausgabe) bezahlen, die für Ihre Arbeitslast erforderlich sind. Wenn der Pufferpool einer MySQL-Datenbank größer als ihr Arbeitssatz ist, können bei einem stabilen Betrieb fast alle Leseabfragen aus dem Pufferpool ausgeführt werden, ohne dass das Laufwerk verwendet wird.

Berücksichtigen Sie bei der Auswahl eines Leistungsniveaus für Ihr Hyperdisk-Volume Ihre MySQL-Schreiblast, wobei Sie insbesondere Folgendes beachten sollten:

  • Zugriff auf InnoDB-Wiederherstellungsprotokolle
  • Nachfolgende Aktualisierungen von InnoDB-Dateien und ‑Indexen

Außerhalb des Normalbetriebs können Datenbankwartungsereignisse auch zu Leistungsspitzen des Laufwerks führen. Die Häufigkeit dieser Fehler hängt in der Regel von der Schreiblast Ihrer Datenbank ab. Daher sind sie in Situationen wie der Wiederherstellung nach einem Absturz mithilfe von Redo-Logs oder einem Sicherungssystem, das sich selbst kopiert, indem alle Datenbankänderungen seit der letzten Sicherung gelesen werden, wahrscheinlicher.

Größe des Laufwerks festlegen

Es gibt drei gängige Strategien für die Festplattenleistung:

  1. Verwenden Sie die Standardkonfiguration. Jedes Laufwerk bietet mindestens 3.000 IOPS (E/A pro Sekunde) und 140 MiB/s Durchsatz. Das reicht für grundlegende MySQL-Arbeitslasten und Bootvolumes des Betriebssystems (OS) aus. Wenn Ihr Anwendungsfall dies übersteigt, können Sie die bereitgestellten I/O-Leistungen bei Bedarf ändern, ohne Ihre Arbeitslast anzuhalten.
  2. Messen Sie Ihre aktuelle Nutzung. Wenn Ihre Datenbank bereits in einer anderen Umgebung ausgeführt wird, erfassen Sie die Laufwerk-IOPS und den Durchsatz mit einer Auflösung von maximal einer Minute. Nachdem Sie ein bis zwei Wochen lang Daten erfasst haben, sodass Ihre Stichprobe einige Schwankungen bei der Auslastung und normale Wartungsereignisse enthält, wählen Sie einen Wert aus dem oberen Perzentil dieses Datensatzes aus und fügen Sie einen kleinen Puffer hinzu, um organisches Wachstum oder unerwartete Nutzung zu berücksichtigen.
  3. Schätzen Sie Ihre Anforderungen ab und ändern Sie sie später. 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 zuzuweisen, als Sie anfangs benötigen, damit es bei Ihrer Arbeitslast nicht zu Leistungsengpässen kommt. Anschließend können Sie die bereitgestellte Leistung auf Ihre Arbeitslast anpassen.

Leistung des Laufwerks steigern

Sie können die Leistung jedes Hyperdisk Balanced-Laufwerks auf maximal 160.000 IOPS und 2.400 MB/s Durchsatz erhöhen. Die Größe Ihrer VM trägt dazu bei, die maximalen Leistungsgrenzen von Hyperdisk zu bestimmen. Wenn Sie 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 Laufwerkleistung erfordern, als ein einzelnes Hyperdisk Balanced-Laufwerk bieten kann, können Sie mit einer der folgenden Methoden mehrere Hyperdisk Balanced-Laufwerke stripen:

  • Auf Hyperdisk Extreme umstellen
  • 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 Laufwerke dynamisch erhöhen, ohne dass es zu Ausfallzeiten kommt. Dies trägt zur Leistung von OLAP-Arbeitslasten (Online Analytical Processing) bei, bei denen große komplexe Joins ausgeführt werden, 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 Datenverluste tolerieren, den gesamten Datensatz auf einem lokalen SSD speichern. Sie können auch die folgenden Hybridlösungen verwenden, um die Leselatenz zu verbessern und die Haltbarkeit zu begrenzen:

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

Zusätzliche Hyperdisk-Funktionen nutzen

Hyperdisk bietet außerdem die folgenden Funktionen, mit denen sich On-Premises-Workflows für Hochverfügbarkeit und Notfallwiederherstellung erweitern oder vereinfachen lassen:

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

Lokale SSDs

Bei einigen Compute Engine-Maschinenfamilien können Sie lokale SSDs anstelle von Hyperdisk verwenden. Dieser Speicher ist nicht dauerhaft, wird aber häufig von MySQL-Workloads zum Speichern von temporären Tablespaces verwendet.

Informationen zur Verwendung lokaler SSDs für die Skalierung von MySQL-Datenbanken finden Sie im Abschnitt Dynamische Laufwerksgröße ändern auf dieser Seite.

Weitere Compute Engine-Funktionen

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

Cloud Monitoring

Mit derGoogle Cloud -Konsole können Sie die Leistung Ihrer VM und die Nutzung von Infrastrukturdiensten überwachen. Auf der Seite VM-Instanzen können Sie auf dem Tab Observability 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 Laufwerkvolumes im Blick behalten.

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

Best Practices für die Konfiguration des Betriebssystems

  • Verwenden Sie ein geeignetes Dateisystem. Google konzentriert sich auf die Optimierung für die Linux-Dateisysteme ext4 und XFS. Die meisten Dateisysteme sind jedoch für die Verwendung mit MySQL geeignet.
  • 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, verwenden Sie die Flags relatime und lazytime für die Bereitstellungskonfiguration des Dateisystems. Dadurch wird der Leistungsoverhead beim Aktualisieren der Werte atime, mtime und ctime in Dateien reduziert, wenn sie gelesen, geändert oder ihre Metadaten geändert werden.

Best Practices für die Konfiguration von MySQL

Wir empfehlen die folgenden Konfigurationseinstellungen für MySQL.

  • Verwenden Sie eine aktuelle Version von MySQL. Google konzentriert sich auf die Optimierung für MySQL 8.0 und höhere Versionen.

  • Erhöhen Sie die Größe des Pufferpools. MySQL verwendet seinen Pufferpool, um die Leseleistung zu verbessern, indem Daten im RAM zwischengespeichert und die Festplattenzugriffe reduziert werden. Standardmäßig beträgt die Größe des Pufferpools von MySQL 128 MiB. Das ist für die meisten praktischen Anwendungsfälle zu wenig. 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. Größe des Arbeitssatzes in einer laufenden Kopie Ihrer MySQL-Instanz messen oder schätzen
    2. Wählen Sie eine Größe und Konfiguration der virtuellen Maschine (VM) mit ausreichend Arbeitsspeicher für diesen Arbeitssatz aus.
    3. Konfigurieren Sie die Größe des Pufferpools auf der VM so, dass er den Großteil des verfügbaren RAM belegt.

  • Aktivieren Sie den Doublewrite-Puffer. MySQL hat einen Doublewrite-Puffer, der vor Torn Writes schützt. Bei diesem Fehlermodus wird ein Schreibvorgang, der mehrere Blöcke auf dem Laufwerk umfasst, möglicherweise nur teilweise bestätigt, wenn während des Schreibvorgangs ein Hardware- oder Stromausfall auftritt. Wenn Sie diesen Schutz nutzen möchten, aktivieren Sie innodb_doublewrite.

  • Legen Sie für innodb_flush_log_at_trx_commit den Wert 1 fest. So wird sichergestellt, dass Schreibtransaktionen beim Commit dauerhaft auf dem Laufwerk gespeichert werden.

  • Geben Sie einen Wert für innodb_flush_method an, um den Leistungsoverhead zu reduzieren. 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 verfügbar. Bei MySQL-Versionen vor 8.0.14 legen Sie den Wert von innodb_flush_method auf O_DIRECT fest.

  • Legen Sie in Replikationsszenarien mit hoher Verfügbarkeit den Wert sync_binlog der primären Datenbankinstanz auf 1 fest. MySQL verwendet sein Binärprotokoll, um Änderungen von der primären Datenbank an die sekundäre Datenbank zu senden. So wird sichergestellt, dass die Binärprotokolle zum Zeitpunkt der Transaktionsbestätigung mit der geringstmöglichen Replikationsverzögerung und dem geringstmöglichen Ziel für den Wiederherstellungspunkt (RPO) zwischen den Datenbanken bestätigt werden.

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

Wann sollte der Doublewrite-Puffer deaktiviert werden?

Der Doublewrite-Puffer von MySQL, der vor abgerissenen Schreibvorgängen schützt, hat einen Leistungsoverhead von bis zu 25% für MySQL-Schreibtransaktionen, was sich potenziell auf die Transaktionslatenz auswirken kann. Google Cloud Hyperdisk bietet auch einen Schutz vor zerrissenen Schreibvorgängen. Wenn Sie also mit MySQL direkt in ein Ext4-Dateisystem schreiben, das auf Hyperdisk ausgeführt wird, können Sie den Doublewrite-Puffer bedenkenlos deaktivieren.

Damit der Schutz vor fehlerhaften Schreibvorgängen von Hyperdisk jedoch effektiv ist, müssen Sie das Dateisystem und andere Zwischensoftwareschichten zwischen Datenbank und Laufwerk konfigurieren, um fehlerhafte Schreibvorgänge über der Laufwerkschicht zu vermeiden. Die folgende Liste enthält Beispiele für Konfigurationen, die zu fehlerhaften Schreibvorgängen über der Hyperdisk-Ebene führen können:

  • Ausführen Ihrer MySQL-Instanz in Containern wie der Google Kubernetes Engine oder einem selbst gehosteten Kubernetes-Cluster
  • MySQL-Dateien in einem XFS-Dateisystem speichern, das in den meisten Linux-Kernelkonfigurationen nicht genügend große Blockgrößen unterstützt
  • Speichern Ihrer MySQL-Dateien auf einer redundanten Anordnung unabhängiger Laufwerke (RAID), die zu Laufwerkstreifen führt, z. B. mdadm für Linux oder Speicherorte und Speicherorte direkt für Windows
  • Speichern Sie Ihre MySQL-Dateien auf einem Volume Manager wie 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 einem lokalen SSD, der als Cache konfiguriert ist, z. B. lvmcache, dm-cache oder bcache für Linux oder Speicherbereiche für Windows.

  • Ausführen Ihrer MySQL-Instanz in einer VM mithilfe der verschachtelten Virtualisierung

Sie können die oben genannten Konfigurationen so einrichten, dass keine unterbrochenen Schreibvorgänge auftreten. Wir empfehlen jedoch, den Puffer für doppelte Schreibvorgänge nicht zu deaktivieren, da es schwierig ist, die Sicherheit einer bestimmten Konfiguration zu überprüfen.

Optional: Puffer für doppelte Schreibvorgänge 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 Zweierpotenz-Mehrfaches von 16 KiB festlegen. So wird sichergestellt, dass die Schreibvorgänge von MySQL nicht vom Dateisystem in separate IOs aufgeteilt werden, bevor sie an Hyperdisk gesendet werden. Wenn Sie das Limit nicht erhöhen oder einen Wert unter 16 KiB verwenden, sind Sie nicht vor unterbrochenen Schreibvorgängen geschützt. Hier ein Beispiel für eine Clustergröße von 16 KiB, die beim Erstellen 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 MySQL-Version wie oben beschrieben).

Hochverfügbarkeit (HA) und eine Sicherungslösung konfigurieren

Wir empfehlen Ihnen dringend, alle Ihre kritischen MySQL-Arbeitslasten zu schützen, indem Sie Hochverfügbarkeits- und Sicherungslösungen für sie konfigurieren. Sowohl für HA als auch für die Sicherung sind die folgenden Faktoren am wichtigsten:

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

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

Hochverfügbarkeit konfigurieren

Mit Hochverfügbarkeitsfunktionen wird Speicher- und Rechenressourcenredundanz genutzt, um die Ausfallzeiten Ihrer MySQL-Datenbank im Falle eines Hostausfalls oder -ausfalls zu reduzieren. So können Clientanwendungen auch dann auf die Daten zugreifen, wenn eine Instanz oder Zone nicht verfügbar ist.

MySQL unterstützt die Replikation in den folgenden Modi:

  • Asynchroner Modus Im asynchronen Modus bestätigt die primäre Instanz Schreibtransaktionen, sobald sie lokal verbindlich gemacht wurden. Bei einem Ausfall der primären Instanz gehen beim Failover möglicherweise einige kürzlich geschriebene Daten verloren, da der RPO zwar nahe bei Null liegt, aber nicht genau Null ist.
  • Semisynchroner Modus Im semisynchronen Modus wartet der primäre Knoten, bis eine konfigurierbare Anzahl von Replicas den Erhalt der Transaktion bestätigt hat, bevor er die Transaktion bestätigt. Dadurch ist die Wahrscheinlichkeit, dass bei einem ungeplanten Failover keine Daten verloren gehen, deutlich höher, da das RPO praktisch null ist.

Für beide Modi wird die RTO davon bestimmt, wie schnell die Systemdiagnosen Folgendes ausführen:

  1. Identifizieren Sie eine fehlgeschlagene Instanz.
  2. Failover auslösen
  3. Informieren Sie die Clients darüber, 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 ist eine Failover-Instanz erforderlich, auf die repliziert werden soll. Sie finden diese Instanz an den folgenden Stellen:

  • In derselben Zone wie die primäre Instanz
  • Eine andere Zone innerhalb der Region, in der sich die primäre Instanz befindet
  • sich in einer anderen Region als die primäre befindet.

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

  • Platzieren Sie die primäre und die Failover-Instanz in verschiedenen Zonen, unabhängig davon, ob sie sich in derselben Region befinden.
  • Verwenden Sie die asynchrone Replikation. Das liegt daran, dass bei der semisynchronen Replikation die Platzierung der primären und Failover-Instanzen in separaten Zonen zu einer hohen Latenz bei Schreibtransaktionen führen kann.
  • Wenn Sie einen RPO von null benötigen, verwenden Sie Hyperdisk mit ausgeglichener Hochverfügbarkeit. Damit können Sie ein Laufwerk synchron über zwei Zonen in derselben Region replizieren. Weitere Informationen finden Sie im Google-Leitfaden zur Bereitstellung von Hochverfügbarkeitsdiensten mit Hyperdisk High Availability. Wenn Sie Hyperdisk mit ausgeglichener Hochverfügbarkeit konfigurieren, empfehlen wir die Einbindung in verwaltete Instanzgruppen mit Status, um Probleme mit der Instanzintegrität zu diagnostizieren und Wiederherstellungsmaßnahmen zu automatisieren.

Sicherungs- und Notfallwiederherstellungsplan konfigurieren

Sicherungs- und Notfallwiederherstellungspläne tragen dazu bei, Datenverluste bei Ausfällen wie versehentlichem Löschen von Daten, Ransomware-Angriffen und Naturkatastrophen zu verhindern. Sie können sie auch als Cold Storage für Compliance- und Prüfungsanforderungen verwenden. Für MySQL gibt es viele Sicherungsmethoden, von denen einige auf Datenbankebene und andere auf Speichervolumenebene ausgeführt werden. Bei der Auswahl einer Methodik sollten Sie in erster Linie Ihre RTO- und RPO-Anforderungen berücksichtigen.

Sicherung auf Datenbankebene

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

  • Inkrementelle Sicherungen basierend auf dem binären Logging,mit denen logische Datendumps 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 Sicherung und Wiederherstellung.

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

Mit Hyperdisk Snapshots auf Speicherebene erstellen und klonen

Für Sicherungen auf Speicherebene empfehlen wir die Verwendung von Hyperdisk-Produkten, um Snapshots zu erstellen, Ihre MySQL-Datenbank zu klonen und anderweitig eine Momentaufnahme zu erfassen. 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 für Sie wichtig ist und Sie nur eine Sicherung innerhalb einer Zone benötigen, empfehlen wir die Verwendung der Instant-Snapshots von Hyperdisk. Mit Instant Snapshots werden Daten zu einem bestimmten Zeitpunkt inkrementell erfasst. Die Daten können dann schnell durch Laufwerkklonen auf einem neuen Hyperdisk-Volume wiederhergestellt werden. Die RTO beträgt nur wenige Minuten. Sie können damit Daten wiederherstellen, wenn der Inhalt eines Laufwerks überschrieben, gelöscht oder beschädigt wurde und lokal in derselben Zone oder Region wie das Quelllaufwerk verfügbar ist. Weitere Informationen finden Sie unter Instant Snapshots.

Für Notfallwiederherstellungsszenarien, in denen Daten mit höherer Redundanz als das Originallaufwerk und an einem separaten Speicherort gespeichert werden müssen, damit sich ein einzelner Notfall nicht auf alle Replikate der Daten auswirkt, empfehlen wir die Verwendung der Archiv- und Standardlaufwerk-Snapshots von Hyperdisk. Archiv- und Standard-Laufwerk-Snapshots erstellen eine Kopie der Daten auf dem Laufwerk zu einem bestimmten Zeitpunkt und speichern sie mit hoher Redundanz in einem unveränderlichen Format. Wenn Sie mehrere Snapshots eines Laufwerks erstellen, z. B. mit einem Snapshot-Zeitplan, speichert Hyperdisk nur inkrementelle Änderungen. Archiv- und Standard-Laufwerk-Snapshots eignen sich gut, wenn Sie eine längere RTO tolerieren können, da die Datenübertragung vom Snapshot-Speicher zurück in den VM-Speicher die Wiederherstellungszeit verlängern kann. Weitere Informationen finden Sie unter Archiv- und Standard-Snapshots für Laufwerke erstellen.

Die Instant-Snapshots, Archiv-Snapshots und Standard-Snapshots von Hyperdisk sind innerhalb eines einzelnen Laufwerks sturzsicher. Das bedeutet, dass bei der Wiederherstellung aus einem Snapshot die normalen Schritte zur InnoDB-Wiederherstellung in Ihrer MySQL-Datenbank ausgeführt werden müssen, um die Protokolle und Datendateien wieder in einen konsistenten Zustand zu versetzen. Je nach Konfiguration des InnoDB-Wiederherstellungsprotokolls kann sich die RTO dadurch verlängern. Die folgenden Muster können das Erstellen eines konsistenten Datenbank-Snapshots weiter 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 Laufwerken verteilt.

So erstellen Sie einen Snapshot, der nach der Wiederherstellung nicht wiederhergestellt werden muss:

  1. Sperren Sie vorübergehend den Schreibzugriff auf die MySQL-Datenbank.
  2. Mit den Befehlen LOCK INSTANCE FOR BACKUP und FLUSH TABLES WITH READ LOCK können Sie alle in Bearbeitung befindlichen Puffer auf das Laufwerk auslagern.
  3. Starten Sie die Snapshot-Vorgänge.

  4. Bei Szenarien mit mehreren Laufwerken müssen Sie nach dem Ausführen des Flush-Befehls auf MySQL-Ebene die Befehle sync und fsfreeze auf dem Server ausführen, um alle laufenden Schreibvorgänge auf das Laufwerk zu übertragen und neue eingehende Schreibvorgänge auf Dateisystemebene anzuhalten.

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

Nächste Schritte