12.3.1 Enabling High Availability on a Standalone DB System
This task requires the following:
- A standalone DB system in the Active state.
- The MySQL configuration of the DB System supports high availability. If it does not, update the MySQL configuration and select a configuration that supports high availability.
- No HeatWave Cluster is attached to the DB System. If there is, delete the HeatWave Cluster.
- Automatic backups are enabled on the DB System. If they are not, see Editing a DB System on how to enable them.
Note:
Optionally, if there has been a high write load on the DB System since the last backup, take a manual backup of the DB System before enabling high availability to speed up the enabling operation. - No data bulk ingestion is running. If bulk ingestion is going on, stop it, or wait until it is finished before enabling high availability.
- No PrivateLinks are attached to the DB System. If there are any, delete them. Once the operation for enabling high availability is completed, reattach the PrivateLinks to the high availability DB System.
- Any replication channel attached to the DB System must use GTID auto-positioning. If it does not, change it by editing the channel.
- Primary keys exist on every table in the database. See Prerequisites on how to check if this is satisfied, and how to add primary keys to your tables if needed.
- 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.
To enable high availability on a standalone DB system, do the following:
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 service events for details of the
failure.
Parent topic: Enabling and Disabling High Availability