文件首頁
MySQL Shell 9.0
下載本手冊
PDF (美式信紙) - 2.3Mb
PDF (A4) - 2.3Mb


MySQL Shell 9.0  /  MySQL InnoDB Cluster  /  修改或解散 InnoDB Cluster

7.9 修改或解散 InnoDB Cluster

本節說明如何將 InnoDB Cluster 從單一主要模式變更為多個主要模式,反之亦然,如何從 InnoDB Cluster 中移除伺服器執行個體,以及如何解散您不再需要的 InnoDB Cluster。

變更叢集的拓撲

依預設,InnoDB Cluster 以單一主要模式執行,其中叢集有一個接受讀取和寫入查詢 (R/W) 的主要伺服器,而叢集中的所有剩餘執行個體僅接受讀取查詢 (R/O)。當您設定叢集以多個主要模式執行時,叢集中的所有執行個體都是主要執行個體,這表示它們同時接受讀取和寫入查詢 (R/W)。如果叢集的所有執行個體都執行 MySQL 伺服器 8.0.15 版或更新版本,您可以在叢集線上時變更叢集的拓撲。在先前的版本中,必須完全解散並重新建立叢集才能進行設定變更。這會使用透過 設定線上群組 中描述的函數公開的群組動作協調器,因此您應該遵守設定線上群組的規則。

注意

多個主要模式被視為進階模式。

通常,單一主要叢集會在目前主要執行個體意外離開叢集時選取新的主要執行個體,例如由於意外停止。選取程序通常用於選擇目前哪些次要執行個體將成為新的主要執行個體。若要覆寫選取程序並強制基礎群組複寫群組中的特定伺服器執行個體成為新的主要執行個體,請使用 Cluster.setPrimaryInstance(instance[, options) 函數,其中 instance 指定應成為新的主要執行個體的執行個體連線。您可以使用 runningTransactionsTimeout 選項,在您使用函數時,為正在執行的交易新增 0 到 3600 秒之間的逾時。當您設定逾時時,發出命令後的傳入交易將會遭到拒絕。

您可以使用下列作業,在單一主要和多個主要之間變更叢集正在執行的模式 (有時會描述為拓撲)

  • Cluster.switchToMultiPrimaryMode(),這會將叢集切換為多個主要模式。所有執行個體都會成為主要執行個體。

  • Cluster.switchToSinglePrimaryMode([instance]),這會將叢集切換為單一主要模式。如果指定 instance,它會成為主要執行個體,而所有其他執行個體都會成為次要執行個體。如果未指定 instance,則新的主要執行個體是成員權重最高的執行個體 (如果成員權重相同,則 UUID 最低)。

從 InnoDB Cluster 移除執行個體

您可以隨時從叢集中移除執行個體 (如果您想要這麼做)。這可以使用 Cluster.removeInstance(instance) 方法來完成,如下列範例所示

mysql-js> cluster.removeInstance('root@localhost:3310')

The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.

Attempting to leave from the Group Replication group...

The instance 'localhost:3310' was successfully removed from the cluster.

cluster.removeInstance() 作業可確保從所有 ONLINE 叢集成員和執行個體本身的元資料中移除執行個體。InnoDB Cluster 中最後一個維持 ONLINE 狀態的執行個體無法使用此作業移除。

當要移除的執行個體有仍需套用的交易時,AdminAPI 會等待最多由 MySQL Shell dba.gtidWaitTimeout 選項設定的秒數,以套用交易 (GTID)。MySQL Shell dba.gtidWaitTimeout 選項的預設值為 60 秒,請參閱 第 13.4 節,「設定 MySQL Shell 選項」,以取得變更預設值的相關資訊。如果在等待套用交易時達到由 dba.gtidWaitTimeout 定義的逾時值,且 force 選項為 false (或未定義),則會發出錯誤並中止移除作業。如果在等待套用交易時達到由 dba.gtidWaitTimeout 定義的逾時值,且 force 選項設定為 true,則作業會繼續執行,而不會發生錯誤,並從叢集中移除執行個體。

注意

Cluster.removeInstance(instance) force 選項會強制從叢集的元資料中移除執行個體。如果執行個體不再是成員,但仍註冊為叢集的一部分,則此選項非常有用。此選項對狀況良好、可連線的執行個體沒有影響,僅會影響無法連線的執行個體或無法與叢集同步的執行個體。

解散 InnoDB Cluster

若要解散 InnoDB Cluster,您可以連線至讀寫執行個體 (例如單一主要叢集中的主要執行個體),並使用 Cluster.dissolve() 命令。這會移除與叢集相關聯的所有元資料和組態,並停用執行個體上的群組複寫。不會移除執行個體之間複寫的任何資料。

重要事項

沒有方法可以復原叢集的解散。若要再次建立,請使用 dba.createCluster()

Cluster.dissolve() 作業只能設定 ONLINE 或可連線的執行個體。如果叢集的成員無法透過您發出 Cluster.dissolve() 命令的成員連線,您必須決定解散作業的執行方式。如果有任何機會想重新加入叢集中識別為遺失的任何執行個體,強烈建議您取消解散作業,並先將遺失的執行個體恢復連線,然後再繼續執行解散作業。這樣可確保所有執行個體都能正確更新其元資料,且不會發生腦裂情況。不過,如果叢集中無法連線的執行個體已永久離開叢集,可能別無選擇,只能強制執行解散作業,這表示會忽略遺失的執行個體,且只有線上執行個體才會受到作業的影響。

警告

強制執行解散作業以忽略叢集執行個體可能會導致在解散作業期間無法連線的執行個體繼續運作,從而產生腦裂情況的風險。只有在您確定執行個體沒有機會再次上線時,才強制執行解散作業以忽略遺失的執行個體。

在互動模式中,如果在解散作業期間無法連線叢集的成員,則會顯示互動式提示,例如

mysql-js> Cluster.dissolve()
The cluster still has the following registered instances:
{
    "clusterName": "testCluster",
    "defaultReplicaSet": {
        "name": "default",
        "topology": [
            {
                "address": "ic-1:3306",
                "label": "ic-1:3306",
                "role": "HA"
            },
            {
                "address": "ic-2:3306",
                "label": "ic-2:3306",
                "role": "HA"
            },
            {
                "address": "ic-3:3306",
                "label": "ic-3:3306",
                "role": "HA"
            }
        ]
    }
}
WARNING: You are about to dissolve the whole cluster and lose the high
availability features provided by it. This operation cannot be reverted. All
members will be removed from the cluster and replication will be stopped,
internal recovery user accounts and the cluster metadata will be dropped. User
data will be maintained intact in all instances.

Are you sure you want to dissolve the cluster? [y/N]: y

ERROR: The instance 'ic-2:3306' cannot be removed because it is on a '(MISSING)'
state. Please bring the instance back ONLINE and try to dissolve the cluster
again. If the instance is permanently not reachable, then you can choose to
proceed with the operation and only remove the instance from the Cluster
Metadata.

Do you want to continue anyway (only the instance metadata will be removed)?
[y/N]: y

Instance 'ic-3:3306' is attempting to leave the cluster...  Instance 'ic-1:3306'
is attempting to leave the cluster...

WARNING: The cluster was successfully dissolved, but the following instance was
skipped: 'ic-2:3306'. Please make sure this instance is permanently unavailable
or take any necessary manual action to ensure the cluster is fully dissolved.

在這個範例中,叢集由三個執行個體組成,其中一個在發出解散 (dissolve) 指令時處於離線狀態。系統會捕獲到此錯誤,並讓您選擇如何繼續。在這個案例中,遺失的 ic-2 執行個體會被忽略,而可連線的成員則會更新其元數據。

當 MySQL Shell 在非互動模式下執行時 (例如執行批次檔案時),您可以使用 force 選項來設定 Cluster.dissolve() 操作的行為。若要強制解散操作忽略任何無法連線的執行個體,請發出以下指令:

mysql-js> Cluster.dissolve({force: true})

任何可以連線的執行個體都會從叢集中移除,而任何無法連線的執行個體則會被忽略。本節中有關強制從叢集中移除遺失執行個體的警告,同樣適用於此種強制解散操作的技巧。

dba.gtidWaitTimeout MySQL Shell 選項會設定 Cluster.dissolve() 操作在將目標執行個體從叢集中移除之前,等待叢集交易被套用的時間長度,但前提是目標執行個體處於 ONLINE 狀態。如果在等待叢集交易被套用至任何要移除的執行個體時達到逾時時間,則會發出錯誤,除非使用了 force: true,在這種情況下會跳過該錯誤。

注意

發出 cluster.dissolve() 後,任何指派給 Cluster 物件的變數都將不再有效。