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, number of CPU count, and amount of RAM defined in the shape chosen. The primary instance functions as a read/write endpoint and you have read/write access to the primary instance only. All data that you write to the primary instance is copied to the secondary instances asynchronously. The binary logs of each MySQL instance are managed independently from each other. Even though the instances have the same data, they can have different number of binary log files with different file names and possibly different sizes.

The secondary instances are placed in different availability or fault domains. The following instance placement models are used:

• Multiple availability domains with a regional subnet: The three MySQL instances are placed in different availability domains.
• Multiple availability domains with an availability domain-specific subnet: The three MySQL instances are placed in different fault domains in the same availability domain.
• Single availability domain region: The three MySQL instances are placed in different fault domains in the same availability domain.

High availability DB systems consume more resources (CPUs, RAM, network bandwidth) than standalone DB systems. Hence the throughput and latency differ from the standalone DB systems.

If you enable automatic backups, MySQL HeatWave Service creates backups of the primary instance of the high availability DB system.

High availability uses MySQL Group Replication to replicate data from the primary instance to the secondary instances. The replication occurs over a secure, managed, internal network, unconnected to the VCN subnet you configured for the DB system. Limited information about this internal network is available in some Performance Schema tables, and you can neither connect to it nor view any other information related to it.

Automatic or Manual Promotion of a Secondary Instance

• Failover: In case the primary instance fails, MySQL 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: MySQL HeatWave Service allows you to manually promote one of the secondary instance as the primary instance. This is called switchover.

During a failover or switchover in a high availability DB system with HeatWave, there is some delay after which you can run queries on HeatWave again.

Preferred and Current Primary Placement

• Preferred primary placement: While creating a high availability DB system, you can choose the availability and fault domain where you want to place the primary instance, which functions as a read/write endpoint. This is called as preferred primary placement, and it does not change once you have created a high availability DB system, except when you perform a switchover. The secondary instances are placed automatically in the other two availability or fault domains.
• Current primary placement: 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 primary placement. The preferred primary placement, which you selected while creating the DB system, remains the same. The IP address of the read/write endpoint does not change, regardless of the placement of the primary instance.

HeatWave Support

You can enable HeatWave on a high availability DB system. To enable HeatWave, first update to a shape that supports HeatWave. See Supported Shapes. The HeatWave cluster adds to the primary instance of the high availability DB system.

• Failover: If the primary instance fails, MySQL 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.
• Switchover: When you perform a switchover, that is, manually promote a secondary instance to a primary instance and demote the earlier primary instance to a secondary instance, the HeatWave cluster attached to the earlier primary instance is deleted and a new HeatWave cluster is attached to the new primary instance.