12.1 Overview of High Availability

A high availability DB System is made up of three MySQL instances: a primary instance and two secondary instances. Each MySQL instance utilizes the same amount of block volume storage, CPU count, and RAM size defined in the chosen shape. The primary instance functions as the only read/write endpoint. All data that you write to the primary instance is copied to the secondary instances asynchronously.

All the three MySQL instances of a high availability DB System are placed in different availability zones (AZs) in the same AWS region containing the DB System.

High availability DB Systems consume more resources (CPUs, RAM, network bandwidth, etc.) than standalone DB Systems. Also, write transactions require coordination and approval by multiple MySQL instances in the high availability DB System. Hence, the throughput and latency for a high availability DB System differ from those of a standalone DB Systems.

A high availability DB System uses MySQL Group Replication to replicate data from the primary instance to the secondary instances. The replication occurs over a secure, managed, internal network. Limited information about this internal network (for example, host names and port numbers) is available in some Performance Schema tables (for example, replication_group_members), and you can neither connect to the internal network nor view any other information related to it. In a Group Replication setup, the binary logs for the different MySQL instances are managed independently from each other: even though the instances have the same data, they might have different number of binary log files with different file names and possibly different sizes.

Promotion of a Secondary Instance

• Failover: In case the primary instance fails, HeatWave Service automatically promotes one of the secondary instances to function as the primary instance. This resumes availability to client applications with no data loss.
• Switchover: HeatWave Service allows you to manually promote one of the secondary instance as the primary instance. This is called a switchover.

Note:

After a failover or switchover, 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.

Preferred and Current Primary Placement

• Preferred primary placement: While creating a high availability DB system, you can choose the AZ where you want to place the primary instance, which functions as a read/write endpoint. This is called the preferred primary placement, and it does not change once you have created a high availability DB system. The secondary instances are placed automatically in two other AZs.
• Current primary placement: When you create a 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 AZ of this new primary instance becomes the current primary placement. The preferred primary placement, which you selected while creating the DB system, remains the same. The DB System can be accessed through the same DB System host name as before, regardless of the placement of the new primary instance.

Related Topics

• Group Replication

Parent topic: High Availability