作為從頭開始建立 ReplicaSet 的替代方案,您可以使用 dba.createReplicaSet()
的 adoptFromAR
選項來採用現有的複製設定。會掃描複製設定,如果它與InnoDB ReplicaSet 限制相容,則 AdminAPI 會建立必要的元資料。採用複製設定後,您只能使用 AdminAPI 來管理 InnoDB ReplicaSet。
若要將現有的複製設定轉換為 InnoDB ReplicaSet,請連線至主要伺服器,也稱為來源。複製拓撲會從 MySQL Shell 執行個體連線的全域工作階段開始,自動掃描並驗證。會在採用期間檢查所有執行個體的設定,以確保它們與 InnoDB ReplicaSet 的使用相容。
所有複製通道都必須處於作用中狀態,並且它們的交易集合(透過 GTID 集合驗證)必須一致。
執行個體假定具有相同的狀態或能夠收斂。
所有新的複製通道都會啟用 SSL 來建立。對於使用 MySQL Shell 8.0.32 採用的複製群組而言,情況並非如此。它們的複製通道保持未加密狀態。
複製拓撲會自動掃描和驗證,從 MySQL Shell 的全域工作階段連線的執行個體開始。此操作對採用的 ReplicaSet 所做的唯一變更是建立元資料結構描述。現有的複製通道在採用期間不會變更,不過您可以在後續的主要切換操作期間變更它們。
例如,要將 example1
和 example2
上 MySQL 伺服器執行個體組成的複製拓撲採用為 InnoDB ReplicaSet。
連線至 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。