

# Configuring active-active clusters for RDS for MySQL
<a name="mysql-active-active-clusters"></a>

An active-active cluster in Amazon RDS is a database configuration where multiple nodes actively handle read and write operations, distributing the workload across instances to improve availability and scalability. Each node in the cluster is synchronized to maintain data consistency, enabling high availability and faster failover in case of node failure

You can set up an active-active cluster for RDS for MySQL by using the MySQL Group Replication plugin. The Group Replication plugin is supported for RDS for MySQL DB instances running the following versions:
+ All MySQL 8.4 versions
+ MySQL 8.0.35 and higher minor versions

For information about MySQL Group Replication, see [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) in the MySQL documentation. The MySQL documentation contains detailed information about this feature, while this topic describes how to configure and manage the plugin on your RDS for MySQL DB instances.

**Note**  
For the sake of brevity, all mentions of "active-active" cluster in this topic refer to active-active clusters using the MySQL Group Replication plugin.

## Use cases for active-active clusters
<a name="mysql-active-active-clusters-benefits"></a>

The following cases are good candidates for using active-active clusters:
+ Applications that need all of the DB instances in the cluster to support write operations. The Group Replication plugin keeps the data consistent on each DB instance in the active-active cluster. For more information about how this works, see [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) in the MySQL documentation.
+ Applications that require continuous availability of the database. With an active-active cluster, the data is retained on the all of the DB instances in the cluster. If one DB instance fails, the application can reroute traffic to another DB instance in the cluster.
+ Applications that might need to split read and write operations among different DB instances in the cluster for load balancing purposes. With an active-active cluster, your applications can send read traffic to specific DB instances and write traffic to others. You can also switch which DB instances to send reads or writes to at any time. 

**Topics**
+ [

## Use cases for active-active clusters
](#mysql-active-active-clusters-benefits)
+ [

# Limitations and considerations for active-active clusters
](mysql-active-active-clusters-considerations-limitations.md)
+ [

# Preparing for a cross-VPC active-active cluster
](mysql-active-active-clusters-cross-vpc-prerequisites.md)
+ [

# Required parameter settings for active-active clusters
](mysql-active-active-clusters-parameters.md)
+ [

# Converting an existing DB instance to an active-active cluster
](mysql-active-active-clusters-converting.md)
+ [

# Setting up an active-active cluster with new DB instances
](mysql-active-active-clusters-setting-up.md)
+ [

# Adding a DB instance to an active-active cluster
](mysql-active-active-clusters-adding.md)
+ [

# Monitoring active-active clusters
](mysql-active-active-clusters-monitoring.md)
+ [

# Stopping Group Replication on a DB instance in an active-active cluster
](mysql-active-active-clusters-stopping.md)
+ [

# Renaming a DB instance in an active-active cluster
](mysql-active-active-clusters-renaming.md)
+ [

# Removing a DB instance from an active-active cluster
](mysql-active-active-clusters-remove.md)

# Limitations and considerations for active-active clusters
<a name="mysql-active-active-clusters-considerations-limitations"></a>

Active-active clusters in Amazon RDS offer enhanced availability and scalability by distributing workloads across multiple instances. However, there are important limitations and considerations to keep in mind when using this architecture.

The following sections outline key factors such as replication delays, conflict resolution, resource allocation, and failover behavior. Understanding these considerations can help ensure optimal performance and reliability in active-active cluster deployments.

**Topics**
+ [

## Limitations for RDS for MySQL active-active clusters
](#mysql-active-active-clusters-limitations)
+ [

## Considerations and best practices for RDS for MySQL active-active clusters
](#mysql-active-active-clusters-considerations)

## Limitations for RDS for MySQL active-active clusters
<a name="mysql-active-active-clusters-limitations"></a>

The following limitations apply to active-active clusters for RDS for MySQL:
+ The master user name can't be `rdsgrprepladmin` for DB instances in an active-active cluster. This user name is reserved for Group Replication connections.
+ For DB instances with read replicas in active-active clusters, a prolonged replication status other than `Replicating` can cause log files to exceed storage limits. For information about the status of read replicas, see [Monitoring read replication](USER_ReadRepl.Monitoring.md).
+ Blue/green deployments aren't supported for DB instances in an active-active cluster. For more information, see [Using Amazon RDS Blue/Green Deployments for database updates](blue-green-deployments.md).
+ Kerberos authentication isn't supported for DB instances in an active-active cluster. For more information, see [Using Kerberos authentication for Amazon RDS for MySQL](mysql-kerberos.md).
+ The DB instances in a Multi-AZ DB cluster can't be added to an active-active cluster. However, the DB instances in a Multi-AZ DB instance deployment can be added to an active-active cluster. For more information, see [Configuring and managing a Multi-AZ deployment for Amazon RDS](Concepts.MultiAZ.md).
+ Tables that don't have a primary key aren't replicated in an active-active cluster because writes are rejected by the Group Replication plugin.
+ Non-InnoDB tables aren't replicated in an active-active cluster.
+ Active-active clusters don't support concurrent DML and DDL statements on different DB instances in the cluster.
+ You can't configure an active-active cluster to use single-primary mode for the group's replication mode. For this configuration, we recommend using a Multi-AZ DB cluster instead. For more information, see [Multi-AZ DB cluster deployments for Amazon RDS](multi-az-db-clusters-concepts.md).
+ Multi-source replication isn't supported for DB instances in an active-active cluster.
+ A cross-Region active-active cluster can't enforce certificate authority (CA) verification for Group Replication connections.

## Considerations and best practices for RDS for MySQL active-active clusters
<a name="mysql-active-active-clusters-considerations"></a>

Before you use RDS for MySQL active-active clusters, review the following considerations and best practices:
+ Active-active clusters can't have more than nine DB instances.
+ With the Group Replication plugin, you can control the transaction consistency guarantees of the active-active cluster. For more information, see [ Transaction Consistency Guarantees](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) in the MySQL documentation.
+ Conflicts are possible when different DB instances update the same row in an active-active cluster. For information about conflicts and conflict resolution, see [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) in the MySQL documentation.
+ For fault tolerance, include at least three DB instances in your active-active cluster. It is possible to configure an active-active cluster with only one or two DB instances, but the cluster won't be fault tolerant. For information about fault tolerance, see [ Fault-tolerance](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) in the MySQL documentation.
+ When a DB instance joins an existing active-active cluster and is running the same engine version as the lowest engine version in the cluster, the DB instance joins in read-write mode.
+ When a DB instance joins an existing active-active cluster and is running a higher engine version than the lowest engine version in the cluster, the DB instance must remain in read-only mode.
+ If you enable Group Replication for a DB instance by setting its `rds.group_replication_enabled` parameter to `1` in the DB parameter group, but replication hasn't started or has failed to start, the DB instance is placed in super-read-only mode to prevent data inconsistencies. For information about super-read-only mode, see the [ MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only).
+ You can upgrade a DB instance in an active-active cluster, but the DB instance is read-only until all of the other DB instances in the active-active cluster are upgraded to same engine version or a higher engine version. When you upgrade a DB instance, the DB instance automatically joins the same active-active cluster when the upgrade completes. To avoid an unintended switch to read-only mode for a DB instance, disable automatic minor version upgrades for it. For information about upgrading a MySQL DB instance, see [Upgrades of the RDS for MySQL DB engine](USER_UpgradeDBInstance.MySQL.md).
+ You can add a DB instance in a Multi-AZ DB instance deployment to an existing active-active cluster. You can also convert a Single-AZ DB instance in an active-active cluster to a Multi-AZ DB instance deployment. If a primary DB instance in a Multi-AZ deployment fails, that primary instance fails over to the standby instance. The new primary DB instance automatically joins the same cluster after failover completes. For more information about Multi-AZ DB instance deployments, see [Multi-AZ DB instance deployments for Amazon RDS](Concepts.MultiAZSingleStandby.md).
+ We recommend that the DB instances in an active-active cluster have different time ranges for their maintenance windows. This practice avoids multiple DB instances in the cluster going offline for maintenance at the same time. For more information, see [Amazon RDS maintenance window](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance).
+ Active-active clusters can use SSL for connections between DB instances. To configure SSL connections, set the [ group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) and [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) parameters. The values for these parameters must match for all DB instances in the active-active cluster.

  Currently, active-active clusters don't support certificate authority (CA) verification for connections between AWS Regions. So, the [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) parameter must be set to `DISABLED` (the default) or `REQUIRED` for cross-Region clusters.
+ An RDS for MySQL active-active cluster runs in multi-primary mode. The default value of the [ group\$1replication\$1enforce\$1update\$1everywhere\$1checks](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) is `ON` and the parameter is static. When this parameter is set to `ON`, applications can't insert into a table that has cascading foreign key constraints.
+ An RDS for MySQL active-active cluster uses the MySQL communication stack for connection security instead of XCOM. For more information, see [ Communication Stack for Connection Security Management](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) in the MySQL documentation.
+ When a DB parameter group is associated with a DB instance in an active-active cluster, we recommend only associating this DB parameter group with other DB instances that are in the cluster.
+ Active-active clusters only support RDS for MySQL DB instances. These DB instances must be running supported versions of the DB engine.
+ When a DB instance in an active-active cluster has an unexpected failure, RDS starts recovery of the DB instance automatically. If the DB instance doesn't recover, we recommend replacing it with a new DB instance by performing a point-in-time recovery with a healthy DB instance in the cluster. For instructions, see [Adding a DB instance to an active-active cluster using point-in-time recovery](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr).
+ You can delete a DB instance in an active-active cluster without affecting the other DB instances in the cluster. For information about deleting a DB instance, see [Deleting a DB instance](USER_DeleteInstance.md).
+ When a DB instance unintentionally leaves an active-active cluster, by default the `group_replication_exit_state_action` parameter changes to `OFFLINE_MODE`. In this state, the DB instance is inaccessible and you must reboot the DB instance to bring it back online and to rejoin the cluster. You can change this behavior by modifying the `group_replication_exit_state_action` parameter in a custom parameter group. By setting the parameter to `READ_ONLY`, when the DB instance unintentionally leaves a cluster, it enters a super read-only state rather than going offline.

# Preparing for a cross-VPC active-active cluster
<a name="mysql-active-active-clusters-cross-vpc-prerequisites"></a>

You can configure an active-active cluster with Amazon RDS for MySQL DB instances in more than one VPC. The VPCs can be in the same AWS Region or different AWS Regions.

**Note**  
Sending traffic between multiple AWS Regions might incur additional costs. For more information, see [Overview of Data Transfer Costs for Common Architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/).

If you are configuring an active-active cluster in a single VPC, you can skip these steps and move on to [Setting up an active-active cluster with new DB instances](mysql-active-active-clusters-setting-up.md).

**To prepare for an active-active cluster with DB instances in more than one VPC**

1. Make sure the IPv4 address ranges in the CIDR blocks meet the following requirements:
   + The IPv4 address ranges in the CIDR blocks of the VPCs can't overlap.
   + All of the IPv4 address ranges in the CIDR blocks either must be lower than `128.0.0.0/subnet_mask` or higher than 128.0.0.0/*subnet\$1mask*.

   The following ranges illustrate these requirements:
   + `10.1.0.0/16` in one VPC and `10.2.0.0/16` in the other VPC is supported.
   + `172.1.0.0/16` in one VPC and `172.2.0.0/16` in the other VPC is supported.
   + `10.1.0.0/16` in one VPC and `10.1.0.0/16` in the other VPC *is not* supported because the ranges overlap.
   + `10.1.0.0/16` in one VPC and `172.1.0.0/16` in the other VPC *is not* supported because one is below `128.0.0.0/subnet_mask` and the other is above `128.0.0.0/subnet_mask`.

   For information about CIDR blocks, see [ VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) in the *Amazon VPC User Guide*.

1. In each VPC, make sure DNS resolution and DNS hostnames are both enabled.

   For instructions, see [ View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) in the *Amazon VPC User Guide*.

1. Configure the VPCs so that you can route traffic between them in one of the following ways:
   + Create a VPC peering connection between the VPCs.

     For instructions, see [ Create a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) in the *Amazon VPC Peering Guide*. In each VPC, make sure there are inbound rules for your security groups that reference security groups in the peered VPC. Doing so allows traffic to flow to and from instances that are associated with the referenced security group in the peered VPC. For instructions, see [ Update your security groups to reference peer security groups](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) in the *Amazon VPC Peering Guide*. 
   + Create a transit gateway between the VPCs.

     For instructions, see [ Getting started with transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) in *Amazon VPC Transit Gateways*. In each VPC, make sure there are inbound rules for your security groups that allow traffic from the other VPC, such as inbound rules that specify the CIDR of the other VPC. Doing so allows traffic to flow to and from instances that are associated with the referenced security group in the active-active cluster. For more information, see [ Control traffic to your AWS resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) in the *Amazon VPC User Guide*.

# Required parameter settings for active-active clusters
<a name="mysql-active-active-clusters-parameters"></a>

Configuring parameters for active-active clusters in Amazon RDS for MySQL is essential for maintaining consistent performance and operational stability. This table details the key parameters that control replication, conflict resolution, and workload distribution. Correct configuration ensures efficient synchronization between nodes, minimizes replication lag, and optimizes resource utilization in distributed or high-traffic environments.


| Parameter | Description | Required setting | 
| --- | --- | --- | 
|  `binlog_format`  |  Sets the binary logging format. The default value for RDS for MySQL 8.0 versions and lower is `MIXED`. The default value for RDS for MySQL 8.4 versions is `ROW`. For more information, see [ the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format).  |  `ROW`  | 
|  `enforce_gtid_consistency`  |  Enforces GTID consistency for statement execution. The default value for RDS for MySQL is `OFF`. For more information, see [ the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency).  |  `ON`  | 
|  `group_replication_group_name`  |  Sets the Group Replication name to a UUID. The UUID format is `11111111-2222-3333-4444-555555555555`. You can generate a MySQL UUID by connecting to a MySQL DB instance and running `SELECT UUID()`. The value must be the same for all of the DB instances in the active-active cluster. For more information, see [ the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid).  |  A MySQL UUID  | 
|  `gtid-mode`  |  Controls GTID-based logging. The default value for RDS for MySQL is `OFF_PERMISSIVE`. For more information, see [ the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode).  |  `ON`  | 
|  `rds.custom_dns_resolution`  |  Specifies whether to allow DNS resolution from the Amazon DNS server in your VPC. DNS resolution must be enabled when Group Replication is enabled with the `rds.group_replication_enabled` parameter. DNS resolution can't be enabled when Group Replication is disabled with the `rds.group_replication_enabled` parameter. For more information, see [ Amazon DNS server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) in the *Amazon VPC User Guide*.  |  `1`  | 
|  `rds.group_replication_enabled`  |  Specifies whether Group Replication is enabled for a DB instance. Group Replication must be enabled on a DB instance in an active-active cluster.  |  `1`  | 
|  `replica_preserve_commit_order` (RDS for MySQL 8.4 and higher versions) or `slave_preserve_commit_order` (RDS for MySQL 8.0 versions)  |  Controls the order that transactions are committed on a replica. The default value for RDS for MySQL is `ON`. For more information, see [ the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order).  |  `ON`  | 

# Converting an existing DB instance to an active-active cluster
<a name="mysql-active-active-clusters-converting"></a>

The DB engine version of the DB instance you want to migrate to an active-active cluster must be one of the following versions:
+ All MySQL 8.4 versions
+ MySQL 8.0.35 and higher minor versions

If you need to upgrade the engine version, see [Upgrades of the RDS for MySQL DB engine](USER_UpgradeDBInstance.MySQL.md).

If you are setting up an active-active cluster with DB instances in more than one VPC, make sure you complete the prerequisites in [Preparing for a cross-VPC active-active cluster](mysql-active-active-clusters-cross-vpc-prerequisites.md).

Complete the following steps to migrate an existing DB instance to an active-active cluster for RDS for MySQL.

**Topics**
+ [

## Step 1: Set the active-active cluster parameters in one or more custom parameter groups
](#mysql-active-active-clusters-converting-parameter-group)
+ [

## Step 2: Associate the DB instance with a DB parameter group that has the required Group Replication parameters set
](#mysql-active-active-clusters-converting-associate-parameter-group)
+ [

## Step 3: Create the active-active cluster
](#mysql-active-active-clusters-converting-associate-parameter-groups)
+ [

## Step 4: Create additional RDS for MySQL DB instances for the active-active cluster
](#mysql-active-active-clusters-converting-add-db-instances)
+ [

## Step 5: Initialize the group on the DB instance you are converting
](#mysql-active-active-clusters-converting-start-replication-first)
+ [

## Step 6: Start replication on the other DB instances in the active-active cluster
](#mysql-active-active-clusters-converting-start-replication-other)
+ [

## Step 7: (Recommended) Check the status of the active-active cluster
](#mysql-active-active-clusters-converting-view)

## Step 1: Set the active-active cluster parameters in one or more custom parameter groups
<a name="mysql-active-active-clusters-converting-parameter-group"></a>

The RDS for MySQL DB instances in an active-active cluster must be associated with a custom parameter group that has the correct setting for required parameters. For information about the parameters and the required setting for each one, see [Required parameter settings for active-active clusters](mysql-active-active-clusters-parameters.md).

You can set these parameters in new parameter groups or in existing parameter groups. However, to avoid accidentally affecting DB instances that aren't part of the active-active cluster, we strongly recommend that you create a new custom parameter group. The DB instances in an active-active cluster can be associated with the same DB parameter group or with different DB parameter groups.

You can use the AWS Management Console or the AWS CLI to create a new custom parameter group. For more information, see [Creating a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). The following example runs the [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI command to create a custom DB parameter group named `myactivepg` for RDS for MySQL 8.0:

For Linux, macOS, or Unix:

```
aws rds create-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --db-parameter-group-family mysql8.0 \
  --description "Parameter group for active-active clusters"
```

For Windows:

```
aws rds create-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --db-parameter-group-family mysql8.0 ^
  --description "Parameter group for active-active clusters"
```

You can also use the AWS Management Console or the AWS CLI to set the parameters in the custom parameter group. For more information, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

The following example runs the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command to set the parameters for RDS for MySQL 8.0. To use this example with RDS for MySQL 8.4, change `slave_preserve_commit_order` to `replica_preserve_commit_order`.

For Linux, macOS, or Unix:

```
aws rds modify-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \
               "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \
               "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \
               "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \
               "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \
               "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \
               "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```

For Windows:

```
aws rds modify-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^
               "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^
               "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^
               "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^
               "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^
               "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^
               "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```

## Step 2: Associate the DB instance with a DB parameter group that has the required Group Replication parameters set
<a name="mysql-active-active-clusters-converting-associate-parameter-group"></a>

Associate the DB instance with a parameter group you created or modified in the previous step. For instructions, see [Associating a DB parameter group with a DB instance in Amazon RDS](USER_WorkingWithParamGroups.Associating.md).

Reboot the DB instance for the new parameter settings to take effect. For instructions, see [Rebooting a DB instance](USER_RebootInstance.md).

## Step 3: Create the active-active cluster
<a name="mysql-active-active-clusters-converting-associate-parameter-groups"></a>

In the DB parameter group associated with the DB instance, set the `group_replication_group_seeds` parameter to the endpoint of the DB instance you are converting.

You can use the AWS Management Console or the AWS CLI to set the parameter. You don't need to reboot the DB instance after setting this parameter. For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

The following example runs the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command to set the parameters:

For Linux, macOS, or Unix:

```
aws rds modify-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```

For Windows:

```
aws rds modify-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```

## Step 4: Create additional RDS for MySQL DB instances for the active-active cluster
<a name="mysql-active-active-clusters-converting-add-db-instances"></a>

To create additional DB instances for the active-active cluster, perform point-in-time recovery on the DB instance you are converting. For instructions, see [Adding a DB instance to an active-active cluster using point-in-time recovery](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr).

An active-active cluster can have up to nine DB instances. Perform point-in-time recovery on the DB instance until you have the number of DB instances you want for the cluster. When you perform point-in-recovery, make sure you associate the DB instance you are adding with a DB parameter group that has `rds.group_replication_enabled` set to `1`. Otherwise, Group Replication won't start on the newly added DB instance.

## Step 5: Initialize the group on the DB instance you are converting
<a name="mysql-active-active-clusters-converting-start-replication-first"></a>

Initialize the group and start replication:

1. Connect to that DB instance you are converting in a SQL client. For more information about connecting to an RDS for MySQL DB instance, see [Connecting to your MySQL DB instance](USER_ConnectToInstance.md).

1. In the SQL client, run the following stored procedures and replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user. The `rdsgrprepladmin` user is reserved for Group Replication connections in an active-active cluster. The password for this user must be the same on all of the DB instances in an active-active cluster.

   ```
   call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
   call mysql.rds_group_replication_create_user('group_replication_user_password');
   call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
   call mysql.rds_group_replication_start(1);
   ```

   This example sets the `binlog retention hours` value to `168`, which means that binary log files are retained for seven days on the DB instance. You can adjust this value to meet your requirements.

   This example specifies `1` in the `mysql.rds_group_replication_start` stored procedure to initialize a new group with the current DB instance.

   For more information about the stored procedures called in the example, see [Managing active-active clusters](mysql-stored-proc-active-active-clusters.md).

## Step 6: Start replication on the other DB instances in the active-active cluster
<a name="mysql-active-active-clusters-converting-start-replication-other"></a>

For each of the DB instances in the active-active cluster, use a SQL client to connect to the instance, and run the following stored procedures. Replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user.

```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(0);
```

This example sets the `binlog retention hours` value to `168`, which means that binary log files are retained for seven days on each DB instance. You can adjust this value to meet your requirements.

This example specifies `0` in the `mysql.rds_group_replication_start` stored procedure to join the current DB instance to an existing group.

**Tip**  
Make sure you run these stored procedures on all of the other DB instances in the active-active cluster.

## Step 7: (Recommended) Check the status of the active-active cluster
<a name="mysql-active-active-clusters-converting-view"></a>

To make sure each member of the cluster is configured correctly, check the status of the cluster by connecting to a DB instance in the active-active cluster, and running the following SQL command:

```
SELECT * FROM performance_schema.replication_group_members;
```

Your output should show `ONLINE` for the `MEMBER_STATE` of each DB instance, as in the following sample output:

```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83  |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```

For information about the possible `MEMBER_STATE` values, see [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in the MySQL documentation.

# Setting up an active-active cluster with new DB instances
<a name="mysql-active-active-clusters-setting-up"></a>

Complete the following steps to set up an active-active cluster using new Amazon RDS for MySQL DB instances.

If you are setting up an active-active cluster with DB instances in more than one VPC, make sure you complete the prerequisites in [Preparing for a cross-VPC active-active cluster](mysql-active-active-clusters-cross-vpc-prerequisites.md).

**Topics**
+ [

## Step 1: Set the active-active cluster parameters in one or more custom parameter groups
](#mysql-active-active-clusters-setting-up-parameter-group)
+ [

## Step 2: Create new RDS for MySQL DB instances for the active-active cluster
](#mysql-active-active-clusters-setting-up-db-instances)
+ [

## Step 3: Specify the DB instances in the active-active cluster
](#mysql-active-active-clusters-setting-up-associate-parameter-groups)
+ [

## Step 4: Initialize the group on a DB instance and start replication
](#mysql-active-active-clusters-setting-up-start-replication-first)
+ [

## Step 5: Start replication on the other DB instances in the active-active cluster
](#mysql-active-active-clusters-setting-up-start-replication-other)
+ [

## Step 6: (Recommended) Check the status of the active-active cluster
](#mysql-active-active-clusters-setting-up-view)
+ [

## Step 7: (Optional) Import data into a DB instance in the active-active cluster
](#mysql-active-active-clusters-import)

## Step 1: Set the active-active cluster parameters in one or more custom parameter groups
<a name="mysql-active-active-clusters-setting-up-parameter-group"></a>

The RDS for MySQL DB instances in an active-active cluster must be associated with a custom parameter group that has the correct setting for required parameters. For information about the parameters and the required setting for each one, see [Required parameter settings for active-active clusters](mysql-active-active-clusters-parameters.md).

You can set these parameters in new parameter groups or in existing parameter groups. However, to avoid accidentally affecting DB instances that aren't part of the active-active cluster, we strongly recommend that you create a new custom parameter group. The DB instances in an active-active cluster can be associated with the same DB parameter group or with different DB parameter groups.

You can use the AWS Management Console or the AWS CLI to create a new custom parameter group. For more information, see [Creating a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). The following example runs the [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI command to create a custom DB parameter group named `myactivepg` for RDS for MySQL 8.0:

For Linux, macOS, or Unix:

```
aws rds create-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --db-parameter-group-family mysql8.0 \
  --description "Parameter group for active-active clusters"
```

For Windows:

```
aws rds create-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --db-parameter-group-family mysql8.0 ^
  --description "Parameter group for active-active clusters"
```

You can also use the AWS Management Console or the AWS CLI to set the parameters in the custom parameter group. For more information, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

The following example runs the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command to set the parameters for RDS for MySQL 8.0. To use this example with RDS for MySQL 8.4, change `slave_preserve_commit_order` to `replica_preserve_commit_order`.

For Linux, macOS, or Unix:

```
aws rds modify-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \
               "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \
               "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \
               "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \
               "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \
               "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \
               "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```

For Windows:

```
aws rds modify-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^
               "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^
               "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^
               "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^
               "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^
               "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^
               "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```

## Step 2: Create new RDS for MySQL DB instances for the active-active cluster
<a name="mysql-active-active-clusters-setting-up-db-instances"></a>

Active-active clusters are supported for the following versions of RDS for MySQL DB instances:
+ All MySQL version 8.4 versions
+ MySQL version 8.0.35 and higher minor versions

You can create up to nine new DB instances for the cluster.

You can use the AWS Management Console or the AWS CLI to create new DB instances. For more information about creating a DB instance, see [Creating an Amazon RDS DB instance](USER_CreateDBInstance.md). When you create the DB instance, associate it with a DB parameter group that you created or modified in the previous step.

## Step 3: Specify the DB instances in the active-active cluster
<a name="mysql-active-active-clusters-setting-up-associate-parameter-groups"></a>

In the DB parameter group associated with each DB instance, set the `group_replication_group_seeds` parameter to the endpoints of the DB instances you want to include in the cluster.

You can use the AWS Management Console or the AWS CLI to set the parameter. You don't need to reboot the DB instance after setting this parameter. For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

The following example runs the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command to set the parameters:

For Linux, macOS, or Unix:

```
aws rds modify-db-parameter-group \
  --db-parameter-group-name myactivepg \
  --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```

For Windows:

```
aws rds modify-db-parameter-group ^
  --db-parameter-group-name myactivepg ^
  --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```

**Tip**  
Make sure you set the `group_replication_group_seeds` parameter in each DB parameter group that is associated with a DB instance in the active-active cluster.

## Step 4: Initialize the group on a DB instance and start replication
<a name="mysql-active-active-clusters-setting-up-start-replication-first"></a>

You can choose any new DB to initialize the group and start replication. To do so, complete the following steps:

1. Choose a DB instance in the active-active cluster, and connect to that DB instance in a SQL client. For more information about connecting to an RDS for MySQL DB instance, see [Connecting to your MySQL DB instance](USER_ConnectToInstance.md).

1. In the SQL client, run the following stored procedures and replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user. The `rdsgrprepladmin` user is reserved for Group Replication connections in an active-active cluster. The password for this user must be the same on all of the DB instances in an active-active cluster.

   ```
   call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
   call mysql.rds_group_replication_create_user('group_replication_user_password');
   call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
   call mysql.rds_group_replication_start(1);
   ```

   This example sets the `binlog retention hours` value to `168`, which means that binary log files are retained for seven days on the DB instance. You can adjust this value to meet your requirements.

   This example specifies `1` in the `mysql.rds_group_replication_start` stored procedure to initialize a new group with the current DB instance.

   For more information about the stored procedures called in the example, see [Managing active-active clusters](mysql-stored-proc-active-active-clusters.md).

## Step 5: Start replication on the other DB instances in the active-active cluster
<a name="mysql-active-active-clusters-setting-up-start-replication-other"></a>

For each of the DB instances in the active-active cluster, use a SQL client to connect to the instance, and run the following stored procedures. Replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user.

```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(0);
```

This example sets the `binlog retention hours` value to `168`, which means that binary log files are retained for seven days on each DB instance. You can adjust this value to meet your requirements.

This example specifies `0` in the `mysql.rds_group_replication_start` stored procedure to join the current DB instance to an existing group.

**Tip**  
Make sure you run these stored procedures on all of the other DB instances in the active-active cluster.

## Step 6: (Recommended) Check the status of the active-active cluster
<a name="mysql-active-active-clusters-setting-up-view"></a>

To make sure each member of the cluster is configured correctly, check the status of the cluster by connecting to a DB instance in the active-active cluster, and running the following SQL command:

```
SELECT * FROM performance_schema.replication_group_members;
```

Your output should show `ONLINE` for the `MEMBER_STATE` of each DB instance, as in the following sample output:

```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83  |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```

For information about the possible `MEMBER_STATE` values, see [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in the MySQL documentation.

## Step 7: (Optional) Import data into a DB instance in the active-active cluster
<a name="mysql-active-active-clusters-import"></a>

You can import data from a MySQL database into a DB instance in the active-active cluster. After the data is imported, Group Replication replicates it to the other DB instances in the cluster.

For information about importing data, see [Importing data to an Amazon RDS for MySQL database with reduced downtime](mysql-importing-data-reduced-downtime.md).

# Adding a DB instance to an active-active cluster
<a name="mysql-active-active-clusters-adding"></a>

You can add a DB instance to an Amazon RDS for MySQL active-active cluster by restoring a DB snapshot or by restoring a DB instance to a point in time. An active-active cluster can include up to nine DB instances.

When you recover a DB instance to a point in time, it usually includes more recent transactions than a DB instance that was restored from a DB snapshot. When the DB instance has more recent transactions, fewer transactions need to be applied when you start replication. So, using point-in-time recovery to add a DB instance to a cluster is usually faster than restoring from a DB snapshot.

**Topics**
+ [

## Adding a DB instance to an active-active cluster using point-in-time recovery
](#mysql-active-active-clusters-adding-pitr)
+ [

## Adding a DB instance to an active-active cluster using a DB snapshot
](#mysql-active-active-clusters-adding-snapshot)

## Adding a DB instance to an active-active cluster using point-in-time recovery
<a name="mysql-active-active-clusters-adding-pitr"></a>

You can add a DB instance to an active-active cluster by performing point-in-time recovery on a DB instance in the cluster.

For information about recovering a DB instance to a point in time in a different AWS Region, see [Replicating automated backups to another AWS Region](USER_ReplicateBackups.md).

**To add a DB instance to an active-active cluster using point-in-time recovery**

1. Create a new DB instance by performing point-in-time recovery on a DB instance in the active-active cluster.

   You can perform point-in-time recovery on any DB instance in the cluster to create the new DB instance. For instructions, see [Restoring a DB instance to a specified time for Amazon RDS](USER_PIT.md).
**Important**  
During point-in-time-recovery, associate the new DB instance with a DB parameter group that has the active-active cluster parameters set. Otherwise, Group Replication won't start on the new DB instance. For information about the parameters and the required setting for each one, see [Required parameter settings for active-active clusters](mysql-active-active-clusters-parameters.md).
**Tip**  
If you take a snapshot of the DB instance before you start point-in-time recovery, you might be able to reduce the amount of time required to apply transactions on the new DB instance.

1. Add the DB instance to the `group_replication_group_seeds` parameter in each DB parameter group associated with a DB instance in the active-active cluster, including the DB parameter group that you associated with the new DB instance.

   For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

1. In a SQL client, connect to the new DB instance, and call the [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel) stored procedure. Replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user.

   ```
   call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
   ```

1. Using the SQL client, call the [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) stored procedure to start replication:

   ```
   call mysql.rds_group_replication_start(0);
   ```

## Adding a DB instance to an active-active cluster using a DB snapshot
<a name="mysql-active-active-clusters-adding-snapshot"></a>

You can add a DB instance to an active-active cluster by creating a DB snapshot of a DB instance in the cluster and then restoring the DB snapshot.

For information about copying a snapshot to a different AWS Region, see [Considerations for cross-Region snapshot copying](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions).

**To add a DB instance to an active-active cluster using a DB snapshot**

1. Create a DB snapshot of a DB instance in the active-active cluster.

   You can create a DB snapshot of any DB instance in the cluster. For instructions, see [Creating a DB snapshot for a Single-AZ DB instance for Amazon RDS](USER_CreateSnapshot.md).

1. Restore a DB instance from the DB snapshot.

   During the snapshot restore operation, associate the new DB instance with a DB parameter group that has the active-active cluster parameters set. For information about the parameters and the required setting for each one, see [Required parameter settings for active-active clusters](mysql-active-active-clusters-parameters.md).

   For information about restoring a DB instance from a DB snapshot, see [Restoring to a DB instance](USER_RestoreFromSnapshot.md).

1. Add the DB instance to the `group_replication_group_seeds` parameter in each DB parameter group associated with a DB instance in the active-active cluster, including the DB parameter group that you associated with the new DB instance.

   For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

1. In a SQL client, connect to the new DB instance, and call the [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel) stored procedure. Replace *group\$1replication\$1user\$1password* with the password for the `rdsgrprepladmin` user.

   ```
   call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
   ```

1. Using the SQL client, call the [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) stored procedure to start replication:

   ```
   call mysql.rds_group_replication_start(0);
   ```

# Monitoring active-active clusters
<a name="mysql-active-active-clusters-monitoring"></a>

Monitoring active-active clusters in Amazon RDS for MySQL is crucial for tracking performance, replication integrity, and node synchronization. You can monitor your active-active cluster by connecting to a DB instance in the cluster, and running the following SQL command:

```
SELECT * FROM performance_schema.replication_group_members;
```

Your output should show `ONLINE` for the `MEMBER_STATE` of each DB instance, as in the following sample output:

```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83  |        3306 | ONLINE       | PRIMARY     | 8.0.35         | MySQL                      |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```

For information about the possible `MEMBER_STATE` values, see [ Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) in the MySQL documentation.

# Stopping Group Replication on a DB instance in an active-active cluster
<a name="mysql-active-active-clusters-stopping"></a>

You can stop Group Replication on a DB instance in an active-active cluster. When you stop Group Replication, the DB instance is placed in super-read-only mode until replication is restarted or that DB instance is removed from the active-active cluster. For information about super-read-only mode, see the [ MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only).

**To stop Group Replication temporarily for an active-active cluster**

1. Connect to a DB instance in the active-active cluster using a SQL client.

   For more information about connecting to an RDS for MySQL DB instance, see [Connecting to your MySQL DB instance](USER_ConnectToInstance.md).

1. In the SQL client, call the [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) stored procedure:

   ```
   call mysql.rds_group_replication_stop();
   ```

# Renaming a DB instance in an active-active cluster
<a name="mysql-active-active-clusters-renaming"></a>

You can change the name of a DB instance in an active-active cluster. To rename more than one DB instance in an active-active cluster, do so one DB instance at a time. So, rename one DB instance and rejoin it to the cluster before you rename the next DB instance.

**To rename a DB instance in an active-active cluster**

1. Connect to the DB instance in a SQL client, and call the [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) stored procedure:

   ```
   call mysql.rds_group_replication_stop();
   ```

1. Rename the DB instance by following the instructions in [Renaming a DB instance](USER_RenameInstance.md).

1. Modify the `group_replication_group_seeds` parameter in each DB parameter group associated with a DB instance in the active-active cluster.

   In the parameter setting, replace the old DB instance endpoint with the new DB instance endpoint. For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

1. Connect to the DB instance in a SQL client, and call the [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) stored procedure:

   ```
   call mysql.rds_group_replication_start(0);
   ```

# Removing a DB instance from an active-active cluster
<a name="mysql-active-active-clusters-remove"></a>

When you remove a DB instance from an active-active cluster, it reverts to a standalone DB instance.

**To remove a DB instance from an active-active cluster**

1. Connect to the DB instance in a SQL client, and call the [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) stored procedure:

   ```
   call mysql.rds_group_replication_stop();
   ```

1. Modify the `group_replication_group_seeds` parameter for the DB instances that will remain in the active-active cluster.

   In the `group_replication_group_seeds` parameter, delete the DB instance that you are removing from the active-active cluster. For more information about setting parameters, see [Modifying parameters in a DB parameter group in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).

1. Modify the parameters of the DB instance you are removing from the active-active cluster so that it is no longer part of the cluster.

   You can either associate the DB instance with a different parameter group, or modify the parameters in the DB parameter group associated with the DB instance. The parameters to modify include `group_replication_group_name`, `rds.group_replication_enabled`, and `group_replication_group_seeds`. For more information about active-active cluster parameters, see [Required parameter settings for active-active clusters](mysql-active-active-clusters-parameters.md).

   If you modify the parameters in a DB parameter group, make sure the DB parameter group isn't associated with other DB instances in the active-active cluster.

1. Reboot the DB instance you removed from the active-active cluster for the new parameter settings to take effect.

   For instructions, see [Rebooting a DB instance](USER_RebootInstance.md).