Überblick über High Availability

Ein High Availability-DB-System besteht aus drei MySQL-Instanzen: einer primären Instanz und zwei sekundären Instanzen. Jede MySQL-Instanz verwendet dieselbe Menge an Block-Volume-Speicher, Anzahl der CPUs und RAM-Menge, die in der ausgewählten Ausprägung definiert ist. Die primäre Instanz fungiert als Lese-/Schreibendpunkt, und Sie haben nur Lese-/Schreibzugriff auf die primäre Instanz. Alle Daten, die Sie in die primäre Instanz schreiben, werden asynchron in die sekundären Instanzen kopiert. Die Binärlogs jeder MySQL-Instanz werden unabhängig voneinander verwaltet. Obwohl die Instanzen dieselben Daten haben, können sie eine unterschiedliche Anzahl von Binärlogdateien mit unterschiedlichen Dateinamen und möglicherweise unterschiedlichen Größen aufweisen.

Die sekundären Instanzen werden in verschiedenen Availability- oder Faultdomains platziert. Folgende Instanzplatzierungsmodelle werden verwendet:

  • Mehrere Verfügbarkeitsdomänen mit einem regionalen Subnetz: Die drei MySQL-Instanzen werden in verschiedenen Verfügbarkeitsdomänen platziert.
  • Mehrere Availability-Domains mit einem für die Availability-Domain spezifischen Subnetz: Die drei MySQL-Instanzen werden in verschiedenen Faultdomains in derselben Availability-Domain platziert.
  • Region mit einer einzelnen Availability-Domain: Die drei MySQL-Instanzen werden in verschiedenen Faultdomains in derselben Availability-Domain platziert.

High Availability-DB-Systeme verbrauchen mehr Ressourcen (CPUs, RAM, Netzwerkbandbreite) als Standalone-DB-Systeme. Daher unterscheiden sich Durchsatz und Latenz von den Standalone-DB-Systemen.

Wenn Sie automatische Backups aktivieren, erstellt der HeatWave-Service Backups der primären Instanz des High Availability-DB-Systems.

High Availability verwendet die MySQL-Gruppenreplikation, um Daten von der primären Instanz in die sekundären Instanzen zu replizieren. Die Replikation erfolgt über ein sicheres, verwaltetes, internes Netzwerk, das nicht mit dem VCN-Subnetz verbunden ist, das Sie für das DB-System konfiguriert haben. In einigen Performance Schema-Tabellen sind begrenzte Informationen zu diesem internen Netzwerk verfügbar, und Sie können weder eine Verbindung damit herstellen noch andere zugehörige Informationen anzeigen.

Automatische oder manuelle Hochstufung einer sekundären Instanz

  • Failover: Wenn die primäre Instanz nicht erfolgreich verläuft, stuft der HeatWave-Service automatisch eine der sekundären Instanzen hoch, damit sie als primäre Instanz fungiert. Dadurch wird die Verfügbarkeit für Clientanwendungen ohne Datenverlust wiederhergestellt.
  • Switchover: Mit dem Service HeatWave können Sie eine der sekundären Instanzen manuell als primäre Instanz hochstufen. Dies wird als Switchover bezeichnet.
Hinweis

Nach einem Failover oder Switchover können der Name und die Position der aktuellen Binärlogdatei der neuen Primärdatenbank von der alten Primärdatenbank abweichen. Da die Binärlogs jeder Instanz unabhängig verwaltet werden, kann jede in den Binärlogs aufgezeichnete Transaktion in eine andere Binärlogdatei und Position in verschiedenen Instanzen geschrieben werden.

Bei einem Failover oder Switchover in einem High-Availability-DB-System mit HeatWave-Cluster tritt eine Verzögerung auf, nach der Sie Abfragen im HeatWave-Cluster erneut ausführen können.

Bevorzugte und aktuelle Hauptplatzierung

  • Bevorzugte primäre Platzierung: Beim Erstellen eines High-Availability-DB-Systems können Sie die Verfügbarkeits- und Faultdomain auswählen, in der Sie die primäre Instanz platzieren möchten, die als Lese-/Schreibendpunkt fungiert. Dies wird als bevorzugte primäre Platzierung bezeichnet und ändert sich nach dem Erstellen eines High-Availability-DB-Systems nicht mehr, es sei denn, Sie führen ein Switchover aus. Die sekundären Instanzen werden automatisch in die anderen beiden Availability- oder Faultdomains platziert.
  • Aktuelle primäre Platzierung: Wenn Sie ein DB-System erstellen, entspricht die aktuelle Platzierung der primären Instanz der bevorzugten Platzierung. Bei einem Failover wird jedoch eine der sekundären Instanzen als primäre Instanz hochgestuft. Die Verfügbarkeits- und Faultdomain dieser neuen primären Instanz ist die aktuelle primäre Platzierung. Die bevorzugte primäre Platzierung, die Sie beim Erstellen des DB-Systems ausgewählt haben, bleibt unverändert. Die IP-Adresse des Lese-/Schreibendpunkts ändert sich nicht, unabhängig von der Platzierung der primären Instanz.

HeatWave Clusterunterstützung

Sie können das HeatWave-Cluster in einem High-Availability-DB-System aktivieren. Um das HeatWave-Cluster zu aktivieren, aktualisieren Sie zuerst die Ausprägung des DB-Systems in eine Ausprägung, die das HeatWave-Cluster unterstützt. Siehe Unterstützte Ausprägungen. Wenn das Cluster HeatWave aktiv ist, wird es immer an die primäre Instanz des High-Availability-DB-Systems angehängt. Wenn sich die aktuelle Position der primären Instanz in einem Failover oder Switchover ändert, muss das Cluster HeatWave von der vorherigen primären Instanz getrennt werden, und dasselbe Cluster oder ein neues Cluster HeatWare muss an die neue primäre Instanz angehängt werden. Die Daten im Cluster HeatWave werden automatisch aus der Speicherebene wiederhergestellt oder aus dem DB-System oder Lakehouse Object Storage neu geladen.

Wenn sich sowohl die vorherige primäre Instanz als auch die neue primäre Instanz in derselben Availability-Domain (AD) befinden, kann das vorhandene HeatWave-Cluster wiederverwendet werden. Das Cluster HeatWave wird von der vorherigen primären Instanz getrennt und wieder an die neue primäre Instanz angehängt. Dies geschieht, wenn sich das DB-System in einer Einzel-AD-Region befindet oder mit einem AD-spezifischen Subnetz in einer Region mit mehreren ADs verbunden ist.

Wenn sich die vorherige primäre Instanz und die neue primäre Instanz in einer anderen Availability-Domain (AD) befinden, muss das vorhandene HeatWave-Cluster getrennt und gelöscht werden. Ein neues HeatWave-Cluster muss in derselben AD wie die neue primäre Instanz erstellt und an die neue primäre Instanz angehängt werden. Dies geschieht, wenn das DB-System mit einem regionalen Subnetz in einer Region mit mehreren ADs verbunden ist.

Verwandte Themen