Building and Using MySQL InnoDB Cluster Set (MICS) for Disaster Recovery

MySQL InnoDB Cluster (MIC) is composed of three components: MySQL Shell for MGR operations, MySQL Router as a read/write split entry point, and MySQL Group Replication (MGR) that stores the actual data.

When using MySQL 8.0, a new feature called MySQL InnoDB Cluster Set (MICS) enables disaster‑recovery by linking two independent MICs through a dedicated clusterset_replication channel.

Key limitations of MICS include:

High‑availability is provided, but consistency is not guaranteed because it relies on asynchronous replication (no semi‑sync).

The replica MIC must be a brand‑new cluster; existing MICs cannot be reused.

Each internal MIC operates in single‑primary mode; multi‑primary is unsupported.

Only one MIC in the set can serve traffic; the others act as standby.

MICS is supported only on MySQL 8.0.

Demo: building a MICS (simplified, without MySQL Router)

Prepare at least six MySQL instances on ports 3381‑3386. MySQL Py > for i in range(3381,3387): dba.deploy_sandbox_instance(i,{"password":"root"})

Create a MySQL Group Replication (MGR) cluster named ytt-rc1 using instances 3381‑3383. MySQL localhost:3381 ssl Py > rc1 = dba.create_cluster('ytt-rc1'); rc1.add_instance("root:root@localhost:3382", {"recoveryMethod":"clone"}); rc1.add_instance("root:root@localhost:3383", {"recoveryMethod":"clone"});

Create a ClusterSet named ytt-rc-set with ytt-rc1 as the primary. MySQL localhost:3381 ssl Py > rc1_set = rc1.create_cluster_set('ytt-rc-set');

Check the ClusterSet status. MySQL localhost:3381 ssl Py > rc1_set.status();

Configure a new instance (3384) as the admin user for replication. MySQL localhost:3381 ssl Py > dba.configure_instance("root:root@localhost:3384", {"clusterAdmin":"ics_admin","clusterAdminPassword":"root"});

Create a replica cluster ytt-rc2 on instance 3384 and add instances 3385 and 3386. MySQL localhost:3381 ssl Py > rc2 = rc1_set.create_replica_cluster("root:root@localhost:3384", "ytt-rc2", {"recoveryMethod":"clone"}); rc2.add_instance("root:root@localhost:3385", {"recoveryMethod":"clone"}); rc2.add_instance("root:root@localhost:3386", {"recoveryMethod":"clone"});

Verify data synchronization by creating a database and table on the primary and checking the replica. MySQL localhost:3381 ssl SQL > create database ytt; use ytt; create table t1(id int primary key, r1 int); insert t1 values (1,100); MySQL localhost:3384 ssl SQL > use ytt; table t1;

Perform a manual failover by promoting ytt-rc2 to primary. MySQL localhost:3384 ssl Py > rc1_set.set_primary_cluster('ytt-rc2');

Check the final status; ytt-rc2 is now PRIMARY and ytt-rc1 is REPLICA. MySQL localhost:3384 ssl Py > rc1_set.status();

Conclusion : MySQL InnoDB Cluster Set provides a convenient disaster‑recovery solution, but because it uses asynchronous replication, users must be aware of potential data lag and consistency issues before adopting it in production.