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.