Failover

In the event of a failure of the primary instance, one of the secondary instances residing in a separate availability or fault domain, is automatically promoted as the primary instance.

Note

After a failover, the current binary log file name and position of the new primary may be different from the old primary. As the binary logs of each instance are managed independently, each transaction recorded in the binary logs may be written to a different binary log file and position in different instances.

When you create a DB system, the current placement of the primary instance is same as the preferred placement. However, in the event of a failover, one of the secondary instances is promoted as the primary instance. The availability and fault domain of this new primary instance is the current placement. The preferred placement of the primary instance, which you selected while creating the DB system, remains the same. In this case, the current placement differs from the preferred placement and a message is displayed on the DB System Details page:

Current placement (<DomainName>) differs from preferred placement, due to failover or maintenance activity.

The <DomainName> is the name of the fault domain or availability domain of the current primary instance.

The IP address of the read/write endpoint of the DB system does not change, regardless of the placement of the primary instance.

Once the error has been corrected, the original primary instance returns to the DB system as a secondary instance. In case there is another failover, the original primary instance is promoted as the current primary instance.

Note

If a failover occurs on a DB system with an active inbound replication channel, the channel is paused until the failover completes. Once failover is complete and a new primary instance is promoted, the channel resumes automatically.

HeatWave Cluster Support

For a high availability DB system with HeatWave cluster, when the primary instance fails, HeatWave Service detaches the HeatWave cluster from the failed primary instance. If the newly promoted primary instance is located in the same availability domain (AD) as the failed primary instance, the same HeatWave cluster is reused and it is attached to the new primary instance. If the newly promoted primary instance is located in a different AD, the existing HeatWave cluster is deleted. A new HeatWave cluster has to be created in the same AD as the new primary instance and it is attached to the new primary instance. The data in the HeatWave cluster is automatically recovered from the Storage Layer or reloaded from the DB system or Lakehouse Object Storage.

Failover Events

When a failover happens, a MySQL - Automatic Recovery event is emitted on the DB system. The additionalDetails.isFailover property of the event is set to true to indicate the automatic recovery is due to a failover. See MySQL - Automatic Recovery.

Failover Reasons

Table 16-1 Failover Reasons

Failover Description
Hardware
  • Storage failures
  • Network failures
  • Availability or fault domain failures
  • Host failures
  • Out of memory issues
MySQL Server
  • MySQL process stops
  • Operating System stops
  • MySQL instance or process is slow or overloaded
  • Replication errors