ApsaraDB RDS:Use the MGR mode

Why use MGR

MGR uses the Paxos protocol to keep all nodes in sync, giving your RDS cluster three properties that asynchronous and semi-synchronous replication cannot guarantee:

• Strong data consistency — if the primary node fails, the cluster automatically removes it and promotes a secondary node. Data on the new primary is consistent with what the failed node had committed.

• High data reliability — a transaction on the primary is committed only after a majority (more than half) of secondary nodes confirm they have received the data, preventing data loss.

• Configurable global transaction consistency — the group_replication_consistency parameter lets you tune read and write consistency per session based on your workload's needs.

MGR delivers lower throughput than asynchronous replication and uses more memory than both asynchronous and semi-synchronous modes. Test performance-sensitive or memory-constrained workloads before switching to MGR.

Prerequisites

Before you begin, verify that your RDS cluster meets all the following requirements. View the RDS edition, major engine version, and instance type on the Basic Information page of the cluster in the ApsaraDB RDS console.

To upgrade from RDS High-availability Edition to RDS Cluster Edition, see Upgrade the RDS edition from RDS High-availability Edition to RDS Cluster Edition. To update the minor engine version, see Update the minor engine version. To upgrade the database proxy version, see Upgrade the database proxy version. To change instance specifications, see Change instance specifications.

Limitations

MGR cannot be enabled if the cluster contains X-Engine tables or tables without primary keys. Run the following queries to check.

Check for X-Engine tables — a result of 0 means no X-Engine tables exist:

SELECT
  COUNT(1)
FROM
  information_schema.TABLES
WHERE
  ENGINE = 'xengine'
  AND table_schema NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'test', 'sys', '__recycle_bin__'
  );

Check for tables without primary keys — a result of 0 means all tables have primary keys:

SELECT
  COUNT(1) AS count
FROM
  information_schema.TABLES t1
  LEFT OUTER JOIN information_schema.columns t2 ON t1.table_schema = t2.TABLE_SCHEMA
  AND t1.table_name = t2.TABLE_NAME
  AND t2.COLUMN_KEY = 'PRI'
WHERE
  t2.table_name IS NULL
  AND t1.table_type = 'BASE TABLE'
  AND t1.TABLE_SCHEMA NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'sys'
  );

For the full list of MySQL Group Replication requirements and limitations, see Requirements and Limitations in the MySQL documentation.

Impacts

Switching from asynchronous or semi-synchronous replication to MGR triggers an instance switchover. Perform the switch during off-peak hours and make sure your application is configured to reconnect automatically. For details on what happens during a switchover, see Impacts of an instance switchover.

Billing

MGR is available at no additional charge.

Enable MGR

Usage notes

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
binlog_format=ROW
binlog_transaction_dependency_tracking=WRITESET
transaction_write_set_extraction=XXHASH64
master_info_repository=TABLE
relay_log_info_repository=TABLE

slave_preserve_commit_order=ON
slave_parallel_type=LOGICAL_CLOCK
rpl_semi_sync_master_enabled=OFF
rpl_semi_sync_slave_enabled=OFF

disabled_storage_engines=MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY,XENGINE
replication_communication_stack=MYSQL
group_replication_single_primary_mode=ON
group_replication_paxos_single_leader=ON
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER

FAQ

Can I switch back from MGR to asynchronous or semi-synchronous replication?

Yes. On the Basic Information page, click Change Data Replication Mode in the Instance Topology Management section, then select the target mode. Switching is bidirectional among asynchronous, semi-synchronous, and MGR.

Can secondary nodes handle read requests in MGR mode?

Yes. However, if secondary nodes are overloaded, write performance on the primary degrades. Enable the database proxy feature with read/write splitting to distribute reads across secondaries while controlling replication latency and read weights. This prevents secondary nodes from becoming a bottleneck.

Does MGR support multi-primary mode?

No. MGR on ApsaraDB RDS for MySQL supports only single-primary mode. Multi-primary mode introduces instability: a jitter or fault on any node affects the availability of the entire cluster.

Why does MGR require at least 8 GB of memory?

MGR adds three sources of memory overhead beyond what normal replication uses:

• The XCom communication layer maintains a message cache of approximately 1 GB.

• The transaction certification module keeps an in-memory certification information array.

• Additional background threads run for group management tasks.

On instances with less than 8 GB of memory, heavy workloads (such as large parallel query bursts) can exhaust available memory and trigger an out-of-memory (OOM) error.

Should I choose a general-purpose or dedicated instance type for MGR?

• 8–16 GB memory: Use a general-purpose instance. Shared physical resources give the MGR processes more flexibility to use memory that other tenants are not consuming.

• 32 GB or more: Use a dedicated instance for stronger resource isolation and more predictable peak performance.

API reference

Next steps

• Introduction to the MGR mode — how MGR works under the hood

• Impacts of an instance switchover — what happens to connections and data during a switchover