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, if the primary instance fails, HeatWave Service deletes the HeatWave cluster attached to the failed primary instance and adds a new one to the new primary instance. The tables that were offloaded to the earlier HeatWave cluster are automatically loaded to the new HeatWave cluster.

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