Failover:
Falls bei der primären Instanz ein Fehler auftritt, wird eine der sekundären Instanzen, die sich in einer separaten Availability- oder Faultdomain befinden, automatisch als primäre Instanz hochgefahren.
Nach einem Failover 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.
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 Platzierung. Die bevorzugte Platzierung der primären Instanz, die Sie beim Erstellen des DB-Systems ausgewählt haben, bleibt unverändert. In diesem Fall unterscheidet sich die aktuelle Platzierung von der bevorzugten Platzierung, und auf der Seite DB-Systemdetails wird eine Meldung angezeigt:
Current placement (<DomainName>) differs from preferred placement, due to failover or maintenance activity. <DomainName> ist der Name der Faultdomain oder Availability-Domain der aktuellen primären Instanz.
Die IP-Adresse des Lese-/Schreibendpunkts des DB-Systems ändert sich nicht, unabhängig von der Platzierung der primären Instanz.
Nachdem der Fehler behoben wurde, kehrt die ursprüngliche primäre Instanz als sekundäre Instanz zum DB-System zurück. Bei einem weiteren Failover wird die ursprüngliche primäre Instanz als aktuelle primäre Instanz hochgestuft.
Wenn ein Failover in einem DB-System mit einem aktiven Inbound-Replikationskanal auftritt, wird der Kanal bis zu seinem Abschluss des Failovers unterbrochen. Wenn der Failover abgeschlossen ist und eine neue primäre Instanz hochgefahren wurde, wird der Kanal automatisch fortgesetzt.
HeatWave Clusterunterstützung
Bei einem High-Availability-DB-System mit dem Cluster HeatWave trennt der HeatWave-Service das Cluster HeatWave von der nicht erfolgreichen primären Instanz, wenn die primäre Instanz nicht erfolgreich ist. Wenn sich die neu hochgestufte Primärinstanz in derselben Availability-Domain (AD) wie die nicht erfolgreiche Primärinstanz befindet, wird dasselbe HeatWave-Cluster wiederverwendet und an die neue Primärinstanz angehängt. Wenn sich die neu hochgestufte Primärinstanz in einer anderen AD befindet, wird das vorhandene HeatWave-Cluster gelöscht. 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. Die Daten im Cluster HeatWave werden automatisch aus der Speicherebene wiederhergestellt oder aus dem DB-System oder Lakehouse Object Storage neu geladen.
Failover-Ereignisse
Wenn ein Failover stattfindet, wird ein Ereignis MySQL - Automatisches Recovery auf dem DB-System ausgegeben. Die Eigenschaft additionalDetails.isFailover des Ereignisses ist auf true gesetzt, um anzugeben, dass das automatische Recovery auf einen Failover zurückzuführen ist. Siehe MySQL - Automatic Recovery.
Failover-Gründe
Tabelle 16-1: Failover-Gründe
| Failover: | Beschreibung |
|---|---|
| Hardware |
|
| MySQL Server |
|