12.4 Failover

In the event of a failure of the primary instance, one of the secondary instances residing in a separate AWS availability zone (AZ), 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 High Availability DB System, the current placement of the primary instance is the 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 zone (AZ) of this new primary instance becomes the current placement. The preferred placement of the primary instance, which you selected while creating the DB system, remains the same.

The DB System host name of the high availability DB system does not change, regardless of the placement of the primary instance.

Once the issue that caused the failover 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.

Failover Reasons

Table 12-1 lists possible reasons for a failover.

Table 12-1 Failover Reasons

Failover	Description
Hardware	Storage failures Network failures Availability Zone 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

Parent topic: High Availability