作为从头开始创建 ReplicaSet 的替代方法，您可以使用 的选项采用现有的复制 adoptFromAR设置 dba.createReplicaSet()。扫描复制设置，如果它与 InnoDB ReplicaSet Limitations兼容，则 AdminAPI 会创建必要的元数据。一旦采用复制设置，您只能使用 AdminAPI 来管理 InnoDB ReplicaSet。
要将现有复制设置转换为 InnoDB ReplicaSet，请连接到主数据库（也称为源）。从实例 MySQL Shell 的已连接全局会话开始，自动扫描和验证复制拓扑。在采用过程中会检查所有实例的配置，以确保它们与 InnoDB ReplicaSet 使用兼容：
- 所有复制通道必须处于活动状态，并且通过 GTID 集验证的事务集必须一致。
- 假设实例具有相同的状态或能够收敛。
笔记
从 8.0.32 开始，所有新的复制通道都是在启用 SSL 的情况下创建的。对于 MySQL Shell 8.0.32 采用的复制组而言，情况并非如此。它们的复制通道保持未加密状态。
从 MySQL Shell 的全局会话连接到的实例开始，复制拓扑会自动扫描和验证。此操作对采用的 ReplicaSet 所做的唯一更改是创建元数据模式。尽管您可以在后续主交换机操作期间更改现有复制通道，但在采用期间不会更改它们。
例如，采用由 InnoDB ReplicaSet example1上 的 MySQL 服务器实例组成的复制拓扑。example2
连接到主要地址example1并发出：
解释mysql-js> rs = dba.createReplicaSet('testadopt', {'adoptFromAR':1})
A new replicaset with the topology visible from 'example1:3306' will be created.
* Scanning replication topology...
** Scanning state of instance example1:3306
** Scanning state of instance example2:3306
* Discovering async replication topology starting with example1:3306
Discovered topology:
- example1:3306: uuid=00371d66-3c45-11ea-804b-080027337932 read_only=no
- example2:3306: uuid=59e4f26e-3c3c-11ea-8b65-080027337932 read_only=no
- replicates from example1:3306
source="localhost:3310" channel= status=ON receiver=ON applier=ON
* Checking configuration of discovered instances...
This instance reports its own address as example1:3306
example1:3306: Instance configuration is suitable.
This instance reports its own address as example2:3306
example2:3306: Instance configuration is suitable.
* Checking discovered replication topology...
example1:3306 detected as the PRIMARY.
Replication state of example2:3306 is OK.
Validations completed successfully.
* Updating metadata...
ReplicaSet object successfully created for example1:3306.
Use rs.addInstance() to add more asynchronously replicated instances to
this replicaset and rs.status() to check its status.
一旦采用了 InnoDB ReplicaSet，您就可以像使用创建的 ReplicaSet 一样使用它。
警告
从此时起，您必须仅使用 AdminAPI 来管理 InnoDB ReplicaSet。
