Oracle Cloud Infrastructure Documentation

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, 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, 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, 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 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.

During a failover or switchover in a high availability DB system with HeatWave cluster, there is some delay after which you can run queries on HeatWave cluster 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 Cluster Support

You can enable HeatWave cluster on a high availability DB system. To enable HeatWave cluster, first update the shape of the DB system to a shape that supports HeatWave cluster. See Supported Shapes. When the HeatWave cluster is active, it is always attached to the primary instance of the high availability DB system. When the current placement of the primary instance changes in a failover or switchover, the HeatWave cluster has to be detached from the previous primary instance and the same or a new HeatWare cluster has to be 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.

If both the previous primary instance and the new primary instance are located in the same availability domain (AD), the existing HeatWave cluster can be reused. The HeatWave cluster is detached from the previous primary instance and reattached to the new primary instance. This happens when the DB system is located in a single-AD region or is connected to an AD-specific subnet in a region with multiple ADs.

If the previous primary instance and the new primary instance are located in different availability domain (AD), the existing HeatWave cluster has to be detached and 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. This happens when the DB system is connected to a regional subnet in a region with multiple ADs.

Related Topics