下載本手冊
PDF (美國信紙) - 2.2Mb
PDF (A4) - 2.3Mb


MySQL Shell 8.4  /  MySQL InnoDB 叢集  /  修改或解散 InnoDB 叢集

7.9 修改或解散 InnoDB 叢集

本節說明如何將 InnoDB 叢集從單一主要模式變更為多重主要模式,或反向變更;如何從 InnoDB 叢集中移除伺服器執行個體;以及如何解散不再需要的 InnoDB 叢集。

變更叢集的拓撲

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

注意

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

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

您可以使用下列作業來變更叢集在單一主要和多重主要之間執行的模式 (有時稱為拓撲)

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

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

從 InnoDB 叢集移除執行個體

您可以隨時從叢集中移除執行個體,如果想要這樣做的話。可以使用 叢集.removeInstance(執行個體) 方法來執行此操作,如下列範例所示

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.

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

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

注意

叢集.removeInstance(執行個體)force 選項會強制從叢集中繼資料中移除執行個體。如果執行個體不再是成員,但仍註冊為叢集的一部分,這會很有用。此選項對健全、可連線的執行個體沒有任何作用,並且僅會影響無法連線的執行個體,或以其他方式無法與叢集同步的執行個體。

解散 InnoDB 叢集

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

重要

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

叢集.dissolve() 作業只能設定處於 ONLINE 或可連線狀態的執行個體。如果您在其中發出 叢集.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.

在此範例中,叢集由三個執行個體組成,其中一個執行個體在發出解散時處於離線狀態。捕捉到錯誤,您有選擇如何繼續的機會。在此情況下,會忽略遺失的 ic-2 執行個體,並更新可連線成員的中繼資料。

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

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

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

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

注意

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