Oracle Cloud Infrastructure Documentation

Enabling or Disabling High Availability

Enabling high availability converts a standalone DB system to a high availability DB system and disabling high availability converts a high availability DB system to a standalone DB system.

  • Enabling high availability on a standalone DB system creates a highly available DB system using the existing MySQL instance as the primary instance, creating two more secondary instances, and replicating the data present in the primary instance to the secondary instances. No downtime occurs.
  • Disabling high availability on a DB system creates a standalone DB system from the instance running in the preferred primary placement.
    • If the primary instance is running in the preferred primary placement, no downtime occurs.
    • If the primary instance is not running in the preferred primary placement, a failover occurs and this causes a short downtime.
      Note

      You can avoid the downtime by switching the preferred primary placement of the DB system to the current primary instance before disabling high availability. See Switchover.
Use one of the following method to enable or disable high availability:

Using the Console

Use the Console to enable or disable high availability on a standalone DB system.

This task requires the following:
  • A running standalone DB system.
  • Primary keys exist on every table in the database. See Prerequisites.
  • Any active inbound replication channel on the DB system must be stopped for the duration of this task. See Enabling or Disabling a Channel. You cannot enable high availability while an active channel is connected to the DB system. This is required only if the configuration used by the DB system is not compatible with high availability. If the DB system is using a compatible configuration, it is not necessary to stop the inbound replication channel to enable high availaibility. Changing the configuration of a DB system requires a restart of the DB system.
  • Crash recovery is enabled. You cannot enable high availability on a DB system if crash recovery is disabled. See Crash Recovery.
  • MySQL version must be 8.0.24 or higher. You cannot enable high availability on earlier versions of MySQL. If the DB system uses a version older than 8.0.24, you must upgrade before enabling high availability.
  • If you intend to configure an inbound replication channel on this DB system, you must import data before enabling high availability, and configure your channel after high availability is enabled.
Note

If you encounter OutOfHostCapacity work request error while enabling high availability in a DB system, see Resolving OutOfHostCapacity Error.
Note

If a HeatWave cluster load or reload operation is going on, enabling or disabling high availability can fail. It is recommended to not enable or disable high availability while a HeatWave cluster load or reload operation is going on.
  1. On the DB systems list page, select the DB system that you want to work with. If you need help finding the list page or the DB system, see Listing DB Systems - Using the Console.

    The details page opens and displays information about the DB system.

  2. Select the Details tab.
  3. To enable high availability on a DB system, do the following:
    1. Select Enable in the High availability field:
    2. In the Enable high availability dialog box:
      • If automatic storage expansion is not enable, enable Automatic storage expansion and enter the Maximum data storage size (GB).
      • Select Enable.
    3. (Optional) If the DB system is not using a high availability-compatible configuration, you must select one from the Configuration drop-down list, and then select Enable.
    The DB system enters the UPDATING state. The secondary instances are cloned from the primary instance and a high availability DB system is formed. The process does not cause any downtime to the DB system. If the updating process fails, the DB system returns to a standalone state. Check the work request for details of the failure.
  4. To disable high availability on a DB system, do the following:
    1. Select Disable in the High availability field:
    2. In the Disable high availability dialog box, select Disable.
    The DB system enters the UPDATING state. If the primary instance is not located in the preferred primary placement, a controlled failover occurs and this causes a short downtime.

    The primary instance located in the preferred primary placement is converted to a standalone DB system and the two secondary instances are deleted. This process does not cause any downtime to the DB system.

Related Topics

Using the CLI

Use the command-line interface to enable or disable high availability on a DB system.

This task requires the following:
  • The OCID of a running DB system.
  • A policy that permits you to update DB system.
  • A properly configured CLI installation. See Command Line Interface.
Do the following to enable or disable high availability on a DB system:
  1. To enable high availability on a DB system, run the following command:
    oci mysql db-system update --db-system-id <DBSystemOCID> 
         --is-highly-available true
    • db-system-id: Specify the OCID of the DB system.
    Note

    If the configuration of the DB system is not compatible with high availability, you must first change the DB system to use a high availability compatible configuration before enabling high availability. See Updating the Configuration of a DB System.
    The DB system enters the UPDATING state. The secondary instances are cloned from the primary instance and a high availability DB system is formed. The process does not cause any downtime to the DB system. If the updating process fails, the DB system returns to a standalone state. Check the work request for details of the failure.
  2. To disable high availability on a DB system, run the following command: 
    oci mysql db-system update --db-system-id <DBSystemOCID> 
         --is-highly-available false
    • db-system-id: Specify the OCID of the DB system.
    The DB system enters the UPDATING state. If the primary instance is not located in the preferred primary placement, a controlled failover occurs and this causes a short downtime.

    The primary instance located in the preferred primary placement is converted to a standalone DB system and the two secondary instances are deleted. This process does not cause any downtime to the DB system.