MySQL :: MySQL Shell 8.4 :: 8.4 部署 InnoDB ClusterSet

版本 8.4

9.0
8.0

MySQL Shell 8.4 / MySQL InnoDB ClusterSet / 部署 InnoDB ClusterSet

8.4 部署 InnoDB ClusterSet

8.4.1 非同步複製通道選項

請按照此程序部署沙箱或生產環境的 InnoDB ClusterSet 部署。沙箱部署是指所有 MySQL 伺服器執行個體和其他軟體都在單一機器上執行。對於生產環境部署，伺服器執行個體和其他軟體位於不同的機器上。

此程序假設您已具備以下元件，如第 8.1 節「InnoDB ClusterSet 需求」中所列。

符合第 8.1 節「InnoDB ClusterSet 需求」中所述需求的現有 InnoDB 叢集。這是 InnoDB ClusterSet 部署支援的主要叢集。
MySQL Shell，已連線至現有的 InnoDB 叢集。MySQL Shell 的 AdminAPI 命令用於部署程序中。
MySQL Router，以針對 InnoDB ClusterSet 進行引導。您已針對現有的 InnoDB 叢集引導的 MySQL Router 執行個體可以在 InnoDB ClusterSet 部署中重複使用，但您需要再次引導它們以實作 InnoDB ClusterSet 組態。
一些獨立的 MySQL 伺服器執行個體 (不屬於 InnoDB 叢集或 InnoDB ReplicaSet) 以組成一個或多個複本叢集。它們必須符合第 8.1 節「InnoDB ClusterSet 需求」中所述的需求。建議每個複本叢集至少要有三個成員伺服器，以容忍故障。

您在 InnoDB ClusterSet 部署程序中使用的使用者帳戶是來自主要叢集的 InnoDB 叢集伺服器組態帳戶。這是使用具有 clusterAdmin 選項的 dba.configureInstance() 命令在主要叢集的成員伺服器上建立的帳戶。每個成員伺服器只有一個伺服器組態帳戶。在叢集中的每個成員伺服器上必須使用相同的使用者帳戶名稱和密碼，您需要在 InnoDB ClusterSet 部署中的所有伺服器上建立它。可以使用 root 帳戶作為 InnoDB 叢集伺服器組態帳戶，但不建議這樣做，因為這表示叢集中每個成員伺服器上的 root 帳戶必須具有相同的密碼。如需更多資訊，請參閱第 8.3 節「InnoDB ClusterSet 的使用者帳戶」。

若要設定 InnoDB ClusterSet 部署，請按照以下程序

使用 InnoDB 叢集伺服器組態帳戶連線至現有 InnoDB 叢集中的任何成員伺服器，以建立連線。例如

mysql-js> \connect icadmin@127.0.0.1:3310

Creating a session to 'icadmin@127.0.0.1:3310'
Please provide the password for 'icadmin@127.0.0.1:3310': **************
Save password for 'icadmin@127.0.0.1:3310'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Closing old connection...
Your MySQL connection id is 59
Server version: 8.0.27-commercial MySQL Enterprise Server - Commercial
No default schema selected; type \use <schema> to set one.
<ClassicSession:icadmin@127.0.0.1:3310>

在此範例中

icadmin@127.0.0.1:3310 是 InnoDB 叢集中任何線上成員伺服器執行個體的 URI 式連線字串。

URI 式連線字串由以下元素組成
icadmin 是 InnoDB 叢集伺服器組態帳戶的使用者名稱。
127.0.0.1:3310 是成員伺服器執行個體的主機和連接埠，由 cluster.status() 命令顯示。

發出 dba.getCluster() 命令以取得代表 InnoDB 叢集的 Cluster 物件，並將其指派給變數，以便您可以使用它。例如
```
mysql-js> cluster1 = dba.getCluster()
<Cluster:clusterone>
```
在此範例中，clusterone 是現有 InnoDB 叢集的名稱，如 cluster.status() 命令傳回的 clusterName 欄位所示，且傳回的 Cluster 物件會指派給變數 cluster1。

當您使用 InnoDB 叢集伺服器組態帳戶連線至伺服器執行個體時，執行此動作非常重要。傳回的物件預設使用取得時使用的帳戶進行需要權限的操作。InnoDB ClusterSet 部署程序中的某些操作需要權限，且儲存在物件中的預設使用者帳戶會用於此，因此該程序不需要儲存任何其他使用者帳戶。
使用 Cluster 物件發出 cluster.createClusterSet() 命令，以將現有的 InnoDB 叢集建立為主要叢集來建立 InnoDB ClusterSet。例如
```
mysql-js> myclusterset = cluster1.createClusterSet('testclusterset')

A new ClusterSet will be created based on the Cluster 'clusterone'.

* Validating Cluster 'clusterone' for ClusterSet compliance.

* Creating InnoDB ClusterSet 'testclusterset' on 'clusterone'...

* Updating metadata...

ClusterSet successfully created. Use ClusterSet.createReplicaCluster() to add Replica Clusters to it.

<ClusterSet:testclusterset>
```
在此範例中，clusterone 是現有 InnoDB 叢集的名稱，cluster1 是指派傳回的 Cluster 物件的變數，testclusterset 是您要建立的 InnoDB ClusterSet 的名稱，而 myclusterset 是指派傳回的 ClusterSet 物件的變數。
- 必須要有 domainName 參數，且指定您要建立的 InnoDB ClusterSet 部署的名稱 (在此範例中為 testclusterset)。
  
  domainName 不得為空，且長度不得超過 63 個字元。它只能以英數字元或 _ (底線) 開頭，且只能包含英數字元、_ (底線)、. (句點) 或 - (連字號) 字元。
- 如果您想要執行驗證並記錄變更，但實際上不執行它們，請使用 dryRun 選項。例如
```
mysql-js> myclusterset = cluster1.createClusterSet('testclusterset', {dryRun: true})
* Validating Cluster 'clusterone' for ClusterSet compliance.

NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
* Creating InnoDB ClusterSet 'clusterset' on 'clusterone'...

* Updating metadata...
dryRun finished.
```
- 如果您想要在 InnoDB ClusterSet 部署中要求或停用複製通道的加密 (TLS/SSL)，請使用 clusterSetReplicationSslMode 選項。預設設定 AUTO 會在伺服器執行個體支援時啟用加密，並在伺服器執行個體不支援時停用加密。REQUIRED 會為所有複製通道啟用加密，而 DISABLED 會為所有複製通道停用加密。例如
```
mysql-js> myclusterset = cluster1.createClusterSet("testclusterset", {clusterSetReplicationSslMode: 'REQUIRED'})
```
clusterSetReplicationSslMode 支援 VERIFY_CA 和 VERIFY_IDENTITY。例如
```
mysql-js> myclusterset = cluster.createClusterSet("testclusterset", {"clusterSetReplicationSslMode":"VERIFY_IDENTITY"});
```
當您發出 cluster.createClusterSet() 命令時，MySQL Shell 會檢查目標 InnoDB 叢集是否符合成為 InnoDB ClusterSet 部署中主要叢集的需求，如果不符合，則會傳回錯誤。如果目標 InnoDB 叢集符合需求，MySQL Shell 會執行以下設定工作
- 更新中繼資料結構描述以包含 InnoDB ClusterSet 中繼資料。
- 將所有成員伺服器上的 skip_replica_start 系統變數設定為 ON，因此不會自動啟動複製執行緒。
- 將目標 InnoDB 叢集新增至中繼資料中的 InnoDB ClusterSet，並將其標記為主要叢集。
- 傳回代表 InnoDB ClusterSet 的 ClusterSet 物件。

使用傳回的 ClusterSet 物件發出 clusterSet.status() 命令，以驗證您已建立的 InnoDB ClusterSet 部署是否運作正常。例如

mysql-js> myclusterset.status()
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310"
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

您也可以使用 cluster.status() 命令來檢視叢集本身。或者，您可以選取 clusterSet.status() 的擴充輸出，以查看 InnoDB ClusterSet 拓撲中叢集的詳細狀態。例如

mysql-js> myclusterset.status({extended: 1})
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-86,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

如需更多資訊和 clusterSet.status() 命令輸出的描述，請參閱第 8.6 節「InnoDB ClusterSet 狀態和拓撲」。

如果您想要隨時取得代表已連線伺服器執行個體的 InnoDB ClusterSet 的 ClusterSet 物件，例如在重新啟動 MySQL Shell 之後，請使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令。例如：

mysql-js> myclusterset = dba.getClusterSet()
<ClusterSet:testclusterset>

將傳回的 Cluster 或 ClusterSet 物件指派給變數，可讓您使用物件的方法對叢集或 ClusterSet 執行進一步的操作。傳回的物件會使用新的工作階段，與 MySQL Shell 的全域工作階段無關。這可確保如果您變更 MySQL Shell 全域工作階段，Cluster 或 ClusterSet 物件會將其工作階段維護在伺服器執行個體中。請注意，當您使用物件時，取得物件的伺服器執行個體必須仍然在 InnoDB ClusterSet 中上線。如果該伺服器執行個體離線，則物件將不再運作，您需要從仍在線上的一台伺服器再次取得該物件。

在將成為複本叢集一部分的每個獨立伺服器執行個體上，透過發出具有 clusterAdmin 選項的 dba.configureInstance() 命令，建立 InnoDB Cluster 伺服器組態帳戶。要建立的帳戶是主要叢集的 InnoDB Cluster 伺服器組態帳戶，您曾用它來建立 ClusterSet。請勿指定任何 InnoDB Cluster 管理員帳戶（使用 cluster.setupAdminAccount() 建立）。這些帳戶將在佈建過程中自動從主要叢集轉移到複本叢集。

您不需要事先連線到獨立伺服器執行個體，因為連線字串已包含在命令中。在連線字串中，請使用具有完整 MySQL 管理員權限的帳戶，包括建立帳戶的權限 (WITH GRANT OPTION)。在此範例中，使用 root 帳戶。
```
mysql-js> dba.configureInstance('root@127.0.0.1:4410', {clusterAdmin: 'icadmin'}) 

Please provide the password for 'root@127.0.0.1:4410': ***************
Save password for 'root@127.0.0.1:4410'? [Y]es/[N]o/Ne[v]er (default No):
Configuring local MySQL instance listening at port 4410 for use in an InnoDB cluster...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.

This instance reports its own address as 127.0.0.1:4410
Password for new account: **************
Confirm password: **************

applierWorkerThreads will be set to the default value of 4.

The instance '127.0.0.1:4410' is valid to be used in an InnoDB cluster.

Cluster admin user 'icadmin' created.
The instance '127.0.0.1:4410' is already ready to be used in an InnoDB cluster.

Successfully enabled parallel appliers.
```
在此範例中，root@127.0.0.1:4410 是獨立伺服器的類 URI 連線字串，而 icadmin 是將在執行個體上建立的 InnoDB Cluster 伺服器組態帳戶的使用者名稱。為了提高安全性，請在互動式提示中指定 InnoDB Cluster 伺服器組態帳戶的密碼，如範例所示，或者您可以使用 clusterAdminPassword 選項提供密碼。dba.configureInstance() 命令會自動授與帳戶所需的權限，不過如果您願意，也可以手動設定帳戶，授與它在手動設定 InnoDB Cluster 管理員帳戶中列出的權限。如需 dba.configureInstance() 命令及其選項的詳細資訊，請參閱第 7.4.2 節，「設定 InnoDB Cluster 使用的生產執行個體」。

當您發出 dba.configureInstance() 時，MySQL Shell 會驗證伺服器執行個體是否符合與 InnoDB Cluster 一起使用的需求。當您發出命令建立複本叢集並將執行個體新增至其中時，會檢查 InnoDB ClusterSet 的需求。
使用 InnoDB Cluster 伺服器組態帳戶，連線到已在 InnoDB ClusterSet 部署中的主要叢集中任何作用中的執行個體。請確保您仍然擁有在建立 InnoDB ClusterSet 時傳回的 ClusterSet 物件，或者使用 dba.getClusterSet() 或 cluster.getClusterSet() 再次擷取它。同樣地，當您使用 InnoDB Cluster 伺服器組態帳戶連線到伺服器執行個體時，這樣做非常重要。物件中儲存的預設使用者帳戶會在 InnoDB ClusterSet 部署程序期間用於某些作業，無論您在連線上指定哪個帳戶。
使用 ClusterSet 物件發出 clusterSet.createReplicaCluster() 命令，以建立複本叢集，並命名其中一個獨立伺服器執行個體。此伺服器執行個體將會是複本叢集的主要伺服器。該命令會傳回複本叢集的 Cluster 物件，如果需要，您可以將此物件指派給變數。例如：
```
mysql-js> cluster2 = myclusterset.createReplicaCluster("127.0.0.1:4410", "clustertwo", {recoveryProgress: 1, timeout: 10}) 
Setting up replica 'clustertwo' of cluster 'clusterone' at instance '127.0.0.1:4410'.

A new InnoDB cluster will be created on instance '127.0.0.1:4410'.

Validating instance configuration at 127.0.0.1:4410...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within 
the same host.

This instance reports its own address as 127.0.0.1:4410

Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44101'. Use the 
localAddress option to override.


* Checking transaction state of the instance...

NOTE: The target instance '127.0.0.1:4410' has not been pre-provisioned (GTID set is empty). The 
Shell is unable to decide whether replication can completely recover its state.
The safest and most convenient way to provision a new instance is through automatic clone 
provisioning, which will completely overwrite the state of '127.0.0.1:4410' with a physical 
snapshot from an existing clusterset member. To use this method by default, set the 
'recoveryMethod' option to 'clone'.

WARNING: It should be safe to rely on replication to incrementally recover the state of the new 
Replica Cluster if you are sure all updates ever executed in the ClusterSet were done with GTIDs 
enabled, there are no purged transactions and the instance used to create the new Replica Cluster 
contains the same GTID set as the ClusterSet or a subset of it. To use this method by default, 
set the 'recoveryMethod' option to 'incremental'.


Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
Waiting for clone process of the new member to complete. Press ^C to abort the operation.
* Waiting for clone to finish...
NOTE: 127.0.0.1:4410 is being cloned from 127.0.0.1:3310
** Stage DROP DATA: Completed

NOTE: 127.0.0.1:4410 is shutting down...

* Waiting for server restart... ready 
* 127.0.0.1:4410 has restarted, waiting for clone to finish...
** Stage FILE COPY: Completed
** Stage PAGE COPY: Completed
** Stage REDO COPY: Completed
** Stage FILE SYNC: Completed
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)

Creating InnoDB cluster 'clustertwo' on '127.0.0.1:4410'...

Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.

* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4410 to 127.0.0.1:3310

* Waiting for instance to synchronize with PRIMARY Cluster...
** Transactions replicated  ############################################################  100%
* Updating topology

Replica Cluster 'clustertwo' successfully created on ClusterSet 'testclusterset'.

<Cluster:clustertwo>
```
對於 clusterSet.createReplicaCluster() 命令：
- instance 參數是必要的，並指定獨立伺服器的 MySQL Server 執行個體的主機和連接埠號碼。這是將成為複本叢集的主要伺服器的伺服器執行個體。在上面的範例命令中，這是 127.0.0.1:4410。
- clusterName 參數是必要的，並指定複本叢集的識別碼。在上面的範例命令中，使用 clustertwo。此名稱在 InnoDB ClusterSet 中必須是唯一的，而且必須遵循 InnoDB Cluster 命名需求。只能使用英數字元、連字號 (-)、底線 (_)，以及句號 (.)，而且名稱不得以數字開頭。最大長度為 63 個字元。叢集名稱區分大小寫。
- 如果您想要執行驗證並記錄變更，但實際上不執行這些變更，請使用 dryRun 選項。
- 如果您想要選取佈建方法，請使用 recoveryMethod 選項。如果您未將此指定為選項，則會使用預設設定 AUTO。在這種情況下，該函數會比較伺服器執行個體上的 GTID 集與主要叢集上的 GTID 集，並嘗試判斷最適合的佈建方法。如果無法判斷，該函數會提示您選取佈建方法，或者如果您不在互動模式下，則會取消作業。
  
  稱為分散式復原的佈建程序可以使用複製，其中伺服器執行個體的狀態完全被從叢集中現有成員伺服器取得的實體快照覆寫。若要事先選取此選項，請指定 CLONE 設定。另一種替代方案是從現有成員伺服器的二進位記錄檔進行增量狀態傳輸，在此案例中，是指主要叢集的成員。在這裡，伺服器執行個體會接收並套用來自它還沒有的主要叢集的交易。若要事先選取此選項，請指定 INCREMENTAL 設定。
- 如果想要選取特定伺服器來提供覆寫目前伺服器的快照（如果透過複製執行分散式復原），請使用 cloneDonor 選項。此作業預設會選取主要叢集的次要成員，或者如果沒有次要成員則選取主要成員。選取的伺服器執行個體必須是 InnoDB ClusterSet 中主要叢集的成員。請指定主機和連接埠號碼。此選項不支援 IPv6 位址。
- 使用 recoveryProgress 選項，為分散式復原程序指定詳細程度 (0、1 或 2)。設定 0 不會顯示進度資訊，設定 1 會顯示詳細的靜態進度資訊，而設定 2 會使用進度列顯示詳細的動態進度資訊。如果標準輸出是終端機，則預設為 2，否則預設為 1。
- 如果您想要設定逾時時間，以等待伺服器執行個體在佈建完成且建立 ClusterSet 複寫通道後與主要叢集同步，請使用 timeout 選項。預設情況下沒有逾時時間。
- 使用 manualStartOnBoot 選項，以指定 Group Replication 在 MySQL 伺服器啟動時是否會自動啟動並重新加入叢集，或者是否必須手動啟動。預設值 false 表示 Group Replication 會自動啟動。
- 使用 communicationStack 選項，使用 XCOM 或 MYSQL 通訊協定來定義成員彼此通訊的方式。請參閱第 7.5.9 節，「設定 Group Replication 通訊堆疊」。
  
  如果您使用的是 MySQL 8.0.27 或更高版本，則預設且建議的通訊協定為 MYSQL。
- 如果您想要為複本 InnoDB Cluster 設定 Group Replication，則可以使用選項 memberSslMode、ipAllowlist、localAddress、exitStateAction、memberWeight、consistency、expelTimeout 和 autoRejoinTries。這些選項的運作方式與不屬於 ClusterSet 的 InnoDB Cluster 的運作方式相同。如需選項的詳細資訊，請參閱第 7.5 節，「設定 InnoDB Cluster」。(注意：ipAllowlist 和 localAddress 僅適用於 XCOM 通訊堆疊。)
- 可以使用選項 localAddress 和 groupName 來設定 Group Replication 的本機位址和群組識別碼。但是，不建議這樣做，因為不正確的值可能會導致 Group Replication 中發生錯誤。僅當您在這些項目的 InnoDB ClusterSet 設定程序所選取的值方面已遇到問題時，才使用這些選項。
- 在建立 InnoDB ClusterSet 時，如果您有安全需求，要求 AdminAPI 自動建立的所有帳戶都具有嚴格的驗證需求，則您可以為 ClusterSet 的 replicationAllowedHost 設定選項設定值。replicationAllowedHost MySQL Shell 選項可讓您將 ClusterSet 的內部管理複寫帳戶設定為嚴格的子網路型篩選器，而不是預設的萬用字元值 %。replicationAllowedHost 選項採用字串值。例如，若要建立名為 my_clusterset_domain 的叢集集，並將 replicationAllowedHost 選項設定為 192.0.2.0/24，請發出：
```
mysql-js> <Cluster>.createClusterSet('my_clusterset_domain', {replicationAllowedHost:'192.0.2.0/24'})
```
  如果您變更 ClusterSet 上的 replicationAllowedHost，則叢集之間用於複寫通道的帳戶會變更為只允許來自您為 replicationAllowedHost 指定的值的連線。主機必須可在主要和複本叢集中存取。如果不能，則叢集之間沒有複寫。
  
  可以在建立之後修改 ClusterSet，以設定 replicationAllowedHost，方法是發出：
```
mysql-js> <Clusterset>.setOption('replicationAllowedHost','192.0.2.0/24')
```
當您發出 clusterSet.createReplicaCluster() 命令時，MySQL Shell 會檢查目標伺服器執行個體是否符合在 InnoDB ClusterSet 部署中成為複本 InnoDB Cluster 中的主要伺服器的需求，如果沒有，則會傳回錯誤。如果執行個體符合需求，MySQL Shell 會執行以下設定工作：
- 建立 ClusterSet 複寫通道 clusterset_replication，並建立具有隨機密碼的複寫使用者。這是目標執行個體與主要叢集的主要伺服器之間由 InnoDB ClusterSet 管理的非同步複寫通道。針對通道，會根據 InnoDB ClusterSet 的 clusterSetReplicationSslMode 選項設定加密。MySQL Shell 會驗證複寫設定是否正常運作，如果沒有，則會傳回錯誤。
- 使用選取的復原方法，透過主要 InnoDB Cluster 的資料集來佈建 MySQL Server 執行個體，並同步 GTID 集。請注意，如果 ClusterSet 的成員伺服器中有大量資料，則分散式復原可能需要數小時。
- 在伺服器執行個體上新增 InnoDB Cluster 管理員帳戶和 MySQL Router 管理員帳戶。如果執行個體是透過二進位日誌的狀態傳輸來佈建的，則佈建過程會包含建立帳戶的交易；否則，這些帳戶會在複製期間傳輸。無論哪種方式，這些帳戶都會在伺服器執行個體上變成可用。請參閱第 8.3 節「InnoDB ClusterSet 的使用者帳戶」以取得更多資訊。
- 為複本叢集設定並啟動 Group Replication。InnoDB ClusterSet 複本叢集建立程序會覆寫您在 clusterSet.createReplicaCluster() 命令上指定新設定的任何現有持續 Group Replication 設定選項。它也總是會覆寫下列設定選項，即使您未在命令中指定它們：group_replication_group_name、group_replication_group_seeds、group_replication_local_address、group_replication_view_change_uuid（僅限版本 8.0.27 到 8.2.0）和 group_replication_enforce_update_everywhere_checks。但是，您在伺服器執行個體上使用於複本叢集之前變更的任何其他 Group Replication 設定選項都會保留原狀。請參閱第 8.1 節「InnoDB ClusterSet 的需求」中關於此的重要說明。
- 將 skip_replica_start 系統變數設定為 ON，以便複寫執行緒不會在伺服器上自動啟動，並設定 super_read_only 系統變數，以便用戶端無法將交易寫入伺服器。
- 停用 Group Replication 成員動作 mysql_disable_super_read_only_if_primary，以便在檢視變更後，叢集的主要伺服器上仍會設定 super_read_only。
- 啟用 Group Replication 成員動作 mysql_start_failover_channels_if_primary，以便為 ClusterSet 複寫通道啟用複本的非同步連線容錯移轉。啟用此功能後，如果正在複寫的主要伺服器離線或進入錯誤狀態，則新的主要伺服器會在選定時在相同通道上啟動複寫。
- 將 ClusterSet 中繼資料傳輸到伺服器執行個體，在 InnoDB ClusterSet 中建立複本叢集，並將目標伺服器執行個體新增為主要伺服器。
- 傳回複本叢集的 Cluster 物件。

使用 clusterSet.createReplicaCluster() 為複本叢集傳回的 Cluster 物件，發出 cluster.addInstance 命令，命名另一個獨立伺服器執行個體。此伺服器執行個體將會是複本叢集中的次要伺服器。例如

mysql-js> cluster2.addInstance('icadmin@127.0.0.1:4420') 

NOTE: The target instance '127.0.0.1:4420' has not been pre-provisioned (GTID set is empty). The 
Shell is unable to decide whether clone based recovery is safe to use.
The safest and most convenient way to provision a new instance is through automatic clone 
provisioning, which will completely overwrite the state of '127.0.0.1:4420' with a physical 
snapshot from an existing cluster member. To use this method by default, set the 
'recoveryMethod' option to 'clone'.

Please select a recovery method [C]lone/[A]bort (default Clone): c
Validating instance configuration at localhost:4420...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within 
the same host.

This instance reports its own address as 127.0.0.1:4420

Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44201'. Use the 
localAddress option to override.

A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.

Adding instance to the cluster...

* Waiting for the Cluster to synchronize with the PRIMARY Cluster...
** Transactions replicated  ############################################################  100% 
* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4420 to 127.0.0.1:3310

Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and 
let it continue in background.
Clone based state recovery is now in progress.

NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.

* Waiting for clone to finish...
NOTE: 127.0.0.1:4420 is being cloned from 127.0.0.1:4410
** Stage DROP DATA: Completed
** Clone Transfer
    FILE COPY  ############################################################  100%  Completed
    PAGE COPY  ############################################################  100%  Completed
    REDO COPY  ############################################################  100%  Completed

NOTE: 127.0.0.1:4420 is shutting down...

* Waiting for server restart... ready
* 127.0.0.1:4420 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)

State recovery already finished for '127.0.0.1:4420'

The instance '127.0.0.1:4420' was successfully added to the cluster.

如需 cluster.addInstance 命令的更多詳細資訊，請參閱第 7.4.4 節「將執行個體新增至 InnoDB 叢集」。

如果您需要再次取得複本叢集的 Cluster 物件，請使用 InnoDB 叢集伺服器設定帳戶連線至複本叢集中任何作用中的執行個體，並發出 dba.getCluster()。此帳戶用於設定程序中的某些操作。如果設定程序發現獨立伺服器執行個體上不存在該帳戶，則會傳回錯誤，您需要發出 dba.configureInstance() 以建立該帳戶。

當命令成功時，伺服器執行個體會新增至複本叢集，並佈建 InnoDB ClusterSet 的資料。複製作業的捐贈者將來自複本叢集，而不是主要叢集。

重複 cluster.addInstance 操作，將所有獨立伺服器執行個體新增至複本叢集。建議至少三個執行個體，以容忍錯誤。您可以在複本叢集中擁有最多九個成員伺服器，這是內建於基礎 Group Replication 技術中的限制。

驗證完成的複本叢集和 InnoDB ClusterSet 部署是否健全。您可以使用 cluster.status() 命令檢視複本叢集，並使用 clusterSet.status() 命令檢視 InnoDB ClusterSet 部署來執行此操作。或者，您可以選取 clusterSet.status() 的擴充輸出，以查看所有叢集的詳細狀態。例如

mysql-js> myclusterset.status({extended: 1}) 
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierStatus": "APPLIED_ALL",
                "applierThreadState": "Waiting for an event from Coordinator",
                "applierWorkerThreads": 4,
                "receiver": "127.0.0.1:4410",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "source": "127.0.0.1:3310"
            },
            "clusterSetReplicationStatus": "OK",
            "globalStatus": "OK",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:4410": {
                    "address": "127.0.0.1:4410",
                    "memberRole": "PRIMARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4420": {
                    "address": "127.0.0.1:4420",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4430": {
                    "address": "127.0.0.1:4430",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "0f6ff279-2764-11ec-ba06-00059a3c7a00:1-5,953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8",
            "transactionSetConsistencyStatus": "OK",
            "transactionSetErrantGtidSet": "",
            "transactionSetMissingGtidSet": ""
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

如需 clusterSet.status() 命令輸出的更多資訊，請參閱第 8.6 節「InnoDB ClusterSet 狀態和拓撲」。

根據需要新增更多複本叢集，方法是對不同的獨立執行個體集重複上述步驟。InnoDB ClusterSet 部署中您可以擁有的複本叢集數量沒有明確的限制。在每種情況下，程序都相同，如下所述
- 透過使用 clusterAdmin 選項發出 dba.configureInstance() 命令，在每個獨立伺服器執行個體上建立 InnoDB 叢集伺服器設定帳戶。
- 當您使用 InnoDB 叢集伺服器設定帳戶連線至 InnoDB ClusterSet 的成員時，使用 dba.getClusterSet() 或 cluster.getClusterSet() 提取 ClusterSet 物件。您可以從主要叢集或您已建立的其中一個複本叢集中的任何成員伺服器取得該物件。
- 使用 ClusterSet 物件發出 clusterSet.createReplicaCluster() 命令，以建立複本叢集，並命名其中一個獨立伺服器執行個體。
- 使用 clusterSet.createReplicaCluster() 為複本叢集傳回的 Cluster 物件，發出 cluster.addInstance 命令，命名另一個獨立伺服器執行個體。
- 重複 cluster.addInstance 操作，將所有獨立伺服器執行個體新增至複本叢集。
- 驗證已完成的複本叢集和 InnoDB ClusterSet 部署是否健全，例如使用具有擴充輸出的 clusterSet.status() 命令。
針對 InnoDB ClusterSet 啟動 MySQL Router 執行個體，以管理應用程式流量，並根據需要設定它們。依預設，MySQL Router 會將所有讀取和寫入請求導向至 InnoDB ClusterSet 部署中目前的主要叢集，但您可以設定 MySQL Router 執行個體，僅將流量路由至特定叢集。如需相關指示，請參閱第 8.5 節「將 MySQL Router 與 InnoDB ClusterSet 整合」。

上一個首頁上一層下一個