はじめに
2021年10月19日、MySQL Server の新マイナーバージョンとなる 8.0.27 がGAとなりました。
例によってリリースノートを眺めてみると、今回も新機能の追加や機能拡張が目白押しですね。
MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.27 (2021-10-19, General Availability)
今回は、追加された新機能のうちの「レプリカの非同期レプリケーション自動フェイルオーバ」について取り上げて確認してみようと思います。
非同期レプリケーション自動フェイルオーバ機能について
ご存じの方も多いかと思いますが、非同期レプリケーション自動フェイルオーバ機能は 8.0.22 で追加されました。
弊社技術ブログでも以前取り上げていますので、詳しくはこちらをご一読いただければと思います。
非同期レプリケーション接続フェイルオーバについて | スマートスタイル TECH BLOG
公式リファレンスマニュアルは以下になります。
今回追加された機能と、これまでの機能と何が異なるか、についてまずは簡単にご紹介します。
8.0.22 時点の機能
上記技術ブログの内容と重複してしまいますが、
予めソースとなるサーバの候補リストを設定し、かつレプリケーションチャネルに SOURCE_CONNECTION_AUTO_FAILOVER=1 を設定した GTID ベースの非同期レプリケーションは、ソースサーバに障害が発生したなどでレプリケーションが切断された場合、候補リストの重み付けに基づき、レプリケーション接続が自動でフェイルオーバされるという機能です。
MySQL :: MySQL 8.0 Reference Manual :: 17.4.9.1 Asynchronous Connection Failover for Sources
これにより、障害時にレプリカ側で手動操作によるレプリケーション張り直しの対応が不要となり、レプリカ側の可用性を高めることが出来ます。
ソースサーバの候補リストを登録・削除するには以下の UDF を用います。
|
1 2 |
asynchronous_connection_failover_add_source(channel, host, port, network_namespace, weight) asynchronous_connection_failover_delete_source(channel, host, port, network_namespace) |
MySQL :: MySQL 8.0 Reference Manual :: 13.4.2.12 Functions which Configure the Source List
8.0.23 での機能拡張
次のリリースで、ソースDB がグループレプリケーションだった場合における機能拡張がなされました。
グループレプリケーションのプライマリメンバーをソースDBとして、別のMySQLインスタンスへ非同期レプリケーションを行っている構成において、
プライマリがフェイルオーバし、別のセカンダリが新たなプライマリに昇格した際、既存の非同期レプリケーションも、新プライマリへと接続フェイルオーバするという機能になります。
また、その後元のプライマリにフェイルバックさせた場合も、非同期レプリケーション接続は追従して自動的に接続し直されます。
設定方法を簡単に紹介します。
-
ソースとなるグループレプリケーション側にて
-
レプリケーション用のユーザーはパフォーマンススキーマへのSELECT権限が必要となるため、事前に付与しておきます。
12例：mysql> GRANT SELECT ON performance_schema.* TO repl_user@`%` -
ソースとなるグループレプリケーションの
group_replication_group_nameを確認しておきます。1mysql> select @@GLOBAL.group_replication_group_name;
-
-
レプリカ側にて
-
事前に
SOURCE_CONNECTION_AUTO_FAILOVER=1をセットした非同期レプリケーション用のチャネルをCHANGE REPLICATION SOURCE TOで設定します。 -
asynchronous_connection_failover_add_managedUDF を用いて、接続フェイルオーバ管理対象グループの設定を行います。12345678910mysql> SELECT asynchronous_connection_failover_add_managed('ch1','GroupReplication','<GR.group_replication_group_name>','<GR.node1.hostname>',<GR.node1.port>,'',80, -- primary_weight60 -- secondary_weight); -
正しく設定されている場合、
mysql.replication_asynchronous_connection_failover_managedテーブルで確認することが出来ます。1234567mysql> SELECT * FROM mysql.replication_asynchronous_connection_failover_managed;+--------------+--------------------------------------+------------------+------------------------------------------------+| Channel_name | Managed_name | Managed_type | Configuration |+--------------+--------------------------------------+------------------+------------------------------------------------+| ch1 | 00023727-bbbb-cccc-dddd-eeeeeeeeeeee | GroupReplication | {"Primary_weight": 80, "Secondary_weight": 60} |+--------------+--------------------------------------+------------------+------------------------------------------------+1 row in set (0.00 sec)
-
-
非同期レプリケーションを開始します。
1START REPLICA for channel 'ch1';レプリケーション接続が成功しプライマリからグループメンバーの情報を取得し、フェイルオーバ候補のリストが自動更新されます。
12345678mysql> SELECT * FROM mysql.replication_asynchronous_connection_failover;+--------------+-----------+-------+-------------------+--------+--------------------------------------+| Channel_name | Host | Port | Network_namespace | Weight | Managed_name |+--------------+-----------+-------+-------------------+--------+--------------------------------------+| ch1 | 127.0.0.1 | 23728 | | 80 | 00023727-bbbb-cccc-dddd-eeeeeeeeeeee || ch1 | 127.0.0.1 | 23729 | | 60 | 00023727-bbbb-cccc-dddd-eeeeeeeeeeee || ch1 | 127.0.0.1 | 23730 | | 60 | 00023727-bbbb-cccc-dddd-eeeeeeeeeeee |+--------------+-----------+-------+-------------------+--------+--------------------------------------+
8.0.27 における新機能
今回のリリースでは、グループレプリケーション同士の非同期レプリケーションにおける、レプリカ側の接続フェイルオーバ機能になります。
MySQL :: MySQL 8.0 Reference Manual :: 17.4.9.2 Asynchronous Connection Failover for Replicas
つまり、ソースとなるグループレプリケーション(GR1と表記)のプライマリからレプリカとなるグループレプリケーション(GR2と表記)に非同期レプリケーションが設定されている場合、GR2のプライマリに障害が発生しGR2のセカンダリが新プライマリに昇格した際、GR2の新プライマリにおいて GR1のプライマリとの非同期レプリケーション接続が自動フェイルオーバされるという機能になります。
※なお、8.0.27 から本機能はデフォルトで有効になりますが、意図的に無効化する場合は、以下のUDFで変更を行います。
|
1 |
mysql> SELECT group_replication_disable_member_action("mysql_start_failover_channels_if_primary", "AFTER_PRIMARY_ELECTION"); |
ここで、すでにご存じの方はピンときたかもしれませんが、同じく 8.0.27 で追加された注目の機能である InnoDB ClusterSet でも用いられることがベースの機能ではないかと察しました。
[ 引用：MySQL :: MySQL Shell 8.0 :: 8 MySQL InnoDB ClusterSet ]
というのも、上記のリファレンスマニュアルには具体的な設定手順が明記されているわけではないということ、および Group replication to Group replication という構成に関して以下の InnoDB Cluster の制限事項の新たに追加された記載も気になったためです。
MySQL :: MySQL Shell 8.0 :: 7.2 InnoDB Cluster Limitations
InnoDB Cluster does not manage manually configured asynchronous replication channels. Group Replication and AdminAPI do not ensure that the asynchronous replication is active on the primary only, and state is not replicated across instances. This can lead to various scenarios where replication no longer works, as well as potentially causing a split brain. Replication between one InnoDB Cluster and another is supported only by InnoDB ClusterSet, which is available from MySQL 8.0.27 and manages replication from an active primary read-write InnoDB Cluster to multiple read-only replica clusters. For information on that solution, see Chapter 8, MySQL InnoDB ClusterSet.
そこで、今回は MySQL Shell の Sandbox 機能を使って InnoDB ClusterSet 構成におけるレプリカの非同期レプリケーション自動フェイルオーバの簡単な機能確認を行ってみました。
MySQL Shell Sandbox 機能で InnoDB ClusterSet を構築する
InnoDB ClusterSet に関しての突っ込んだ検証はまたの機会ということにし、今回は非同期レプリケーション自動フェイルオーバ機能に焦点を当てて確認を進めていきます。
mysql-commynity-server, mysql-shell をインストール済みの環境を使います。
メモリは 4GB では確実に不足するのでその倍程度は合ったほうがいいかと思います。
InnDB ClusterSet の構築手順は以下のリファレンスマニュアルの内容をほぼそのままなぞって進めていきます。
MySQL :: MySQL Shell 8.0 :: 8.4 Deploying InnoDB ClusterSet
1. サンドボックスインスタンスの作成と InnoCB Cluster(cluster1) の作成
これ自体は既出の内容ですので、説明は割愛します。
途中、root ユーザーのパスワード設定が促されますが、全てのインスタンスで統一しておきます。
|
1 2 3 4 5 6 7 8 9 |
# mysqlsh MySQL JS > dba.deploySandboxInstance(3310) MySQL JS > dba.deploySandboxInstance(3320) MySQL JS > dba.deploySandboxInstance(3330) MySQL JS > \c root@localhost:3310 MySQL localhost:3310 ssl JS > cluster1 = dba.createCluster('clusterone') MySQL localhost:3310 ssl JS > cluster1.addInstance('root@127.0.0.1:3320') MySQL localhost:3310 ssl JS > cluster1.addInstance('root@127.0.0.1:3330') |
2. クラスタセットの作成
マニュアル通り testclusterset という名前のクラスタセットを作成します。(任意の名前で構いませんが)
|
1 2 3 4 5 6 7 8 9 10 11 12 |
MySQL localhost:3310 ssl 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> |
クラスタセットの状態を以下のAPIコマンドで確認することが出来ます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
MySQL localhost:3310 ssl SQL > 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." } |
3. レプリカクラスタの作成
新しいインスタンスを追加で作成し、そこに先ほどの clusterone を元にレプリカクラスタ(clustertwo)を作成します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
MySQL localhost:3310 ssl JS > dba.deploySandboxInstance(3410); MySQL localhost:3310 ssl JS > cluster2 = myclusterset.createReplicaCluster("127.0.0.1:3410", "clustertwo", {recoveryProgress: 1, timeout: 10}) Setting up replica 'clustertwo' of cluster 'clusterone' at instance '127.0.0.1:3410'. A new InnoDB cluster will be created on instance '127.0.0.1:3410'. Validating instance configuration at 127.0.0.1:3410... 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:3410 Instance configuration is suitable. NOTE: Group Replication will communicate with other members using '127.0.0.1:34101'. Use the localAddress option to override. * Checking transaction state of the instance... NOTE: The target instance '127.0.0.1:3410' 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:3410' 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): C 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:3410 is being cloned from 127.0.0.1:3310 ** Stage DROP DATA: Completed ** Stage FILE COPY: Completed ** Stage PAGE COPY: Completed ** Stage REDO COPY: Completed NOTE: 127.0.0.1:3410 is shutting down... * Waiting for server restart... ready * 127.0.0.1:3410 has restarted, waiting for clone to finish... ** Stage FILE SYNC: Completed ** Stage RESTART: Completed * Clone process has finished: 72.77 MB transferred in about 1 second (~72.77 MB/s) Creating InnoDB cluster 'clustertwo' on '127.0.0.1:3410'... 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:3410 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> |
無事レプリカクラスタが作成されました。
Configuring ClusterSet managed replication channel... のメッセージがある通り、この時点でプライマリクラスタである clusterone とのレプリケーション設定が構成されたようです。
続けてレプリカクラスタのメンバー追加を行います。
|
1 2 3 4 |
MySQL localhost:3310 ssl JS > dba.deploySandboxInstance(3420); MySQL localhost:3310 ssl JS > dba.deploySandboxInstance(3430); MySQL localhost:3310 ssl JS > cluster2.addInstance('root@127.0.0.1:3420') MySQL localhost:3310 ssl JS > cluster2.addInstance('root@127.0.0.1:3430') |
クラスタセットの状態確認で、extended オプションを有効化すると、クラスタセット全体の詳細情報を取得することが出来ました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 |
MySQL localhost:3310 ssl 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": "31c42927-37be-11ec-a6d5-00163e3da7cd:1-103,31c42e65-37be-11ec-a6d5-00163e3da7cd:1-5" }, "clustertwo": { "clusterRole": "REPLICA", "clusterSetReplication": { "applierStatus": "APPLIED_ALL", "applierThreadState": "Waiting for an event from Coordinator", "applierWorkerThreads": 4, "receiver": "127.0.0.1:3410", "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:3410": { "address": "127.0.0.1:3410", "memberRole": "PRIMARY", "mode": "R/O", "replicationLagFromImmediateSource": "", "replicationLagFromOriginalSource": "", "status": "ONLINE", "version": "8.0.27" }, "127.0.0.1:3420": { "address": "127.0.0.1:3420", "memberRole": "SECONDARY", "mode": "R/O", "replicationLagFromImmediateSource": "", "replicationLagFromOriginalSource": "", "status": "ONLINE", "version": "8.0.27" }, "127.0.0.1:3430": { "address": "127.0.0.1:3430", "memberRole": "SECONDARY", "mode": "R/O", "replicationLagFromImmediateSource": "", "replicationLagFromOriginalSource": "", "status": "ONLINE", "version": "8.0.27" } }, "transactionSet": "31c42927-37be-11ec-a6d5-00163e3da7cd:1-103,31c42e65-37be-11ec-a6d5-00163e3da7cd:1-5,d15c9b6e-37c1-11ec-b519-00163e3da7cd:1-5", "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." } |
InnoCB ClusterSet における非同期レプリケーションおよび自動フェイルオーバ機能の確認
1. 状態確認
クラスタセットが完成した時点での、ソース側(clusterone) プライマリに接続されたレプリカを確認してみます。
|
1 2 3 4 5 6 7 |
MySQL localhost:3310 ssl SQL > SHOW REPLICAS; +------------+-----------+------+------------+--------------------------------------+ | Server_Id | Host | Port | Source_Id | Replica_UUID | +------------+-----------+------+------------+--------------------------------------+ | 3259784411 | 127.0.0.1 | 3410 | 2876111632 | a433be99-37c1-11ec-9539-00163e3da7cd | +------------+-----------+------+------------+--------------------------------------+ 1 row in set (0.0002 sec) |
想定通り、clustertwo のプライマリ(127.0.0.1:3410)がレプリカとして接続されています。
レプリカ側でレプリケーション詳細情報(抜粋)を確認してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
MySQL localhost:3410 ssl SQL > SHOW REPLICA STATUS\G *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: 127.0.0.1 Source_User: mysql_innodb_cs_c24c5cdb Source_Port: 3310 Replica_IO_Running: Yes Replica_SQL_Running: Yes Source_Server_Id: 2876111632 Source_UUID: 728e81de-37bd-11ec-a416-00163e3da7cd Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates Source_Retry_Count: 10 Auto_Position: 1 Channel_Name: clusterset_replication Source_public_key_path: Get_Source_public_key: 1 Network_Namespace: 1 row in set (0.0002 sec) |
clusterset_replication というチャネル名で構成されています。
I/Oスレッド、SQLスレッド共に正常に動作しています。
フェイルオーバ候補リストを確認してみます。
|
1 2 3 4 5 6 7 8 |
MySQL localhost:3410 ssl SQL > SELECT * FROM performance_schema.replication_asynchronous_connection_failover; +------------------------+-----------+------+-------------------+--------+--------------------------------------+ | CHANNEL_NAME | HOST | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME | +------------------------+-----------+------+-------------------+--------+--------------------------------------+ | clusterset_replication | 127.0.0.1 | 3310 | | 80 | 31c42927-37be-11ec-a6d5-00163e3da7cd | | clusterset_replication | 127.0.0.1 | 3320 | | 60 | 31c42927-37be-11ec-a6d5-00163e3da7cd | | clusterset_replication | 127.0.0.1 | 3330 | | 60 | 31c42927-37be-11ec-a6d5-00163e3da7cd | +------------------------+-----------+------+-------------------+--------+--------------------------------------+ |
clusterone のグループメンバーが自動的に登録されています。
SOURCE_CONNECTION_AUTO_FAILOVER も有効化されていることが分かります。
|
1 2 3 4 5 6 7 8 9 |
MySQL localhost:3410 ssl SQL > SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration WHERE CHANNEL_NAME = 'clusterset_replication'; +------------------------+---------------------------------+ | CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER | +------------------------+---------------------------------+ | clusterset_replication | 1 | +------------------------+---------------------------------+ |
リファレンスマニュアルの記載にありますが、非同期レプリケーションチャネル設定済みのノードをクローンしてグループレプリケーションを構成する場合、設定がそのまま複製されるので手動で設定する必要はないようです。
また、グループに新たに追加したメンバーに対しても、設定が自動的に伝搬される（後から SOURCE_CONNECTION_AUTO_FAILOVER=0 で非同期レプリケーションフェイルオーバを無効化した場合でもそれが伝搬される）仕組みになっています。
クローン機能とグループレプリケーションを生かしたシンプルで効率の良い方法と言えますね。
また、Deploying InnoDB ClusterSet のページにも明記されていますが、レプリカクラスタを作成すると API が自動で各種設定を実施します。
例えば、レプリカクラスタはプライマリでも read_only super_read_only がONになります。
また、セカンダリが再起動してしまったときに非同期レプリケーションチャネルが自動で開始しないように skip_replica_start に設定されるのが特徴的です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
MySQL localhost:3410 ssl SQL > SHOW GLOBAL VARIABLES LIKE '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | ON | | super_read_only | ON | | transaction_read_only | OFF | +-----------------------+-------+ 4 rows in set (0.0017 sec) MySQL localhost:3410 ssl SQL > SHOW GLOBAL VARIABLES LIKE 'skip_replica_start' ; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | skip_replica_start | ON | +--------------------+-------+ 1 row in set (0.0010 sec) |
2. レプリカになっているプライマリメンバーの停止時
早速、今回の肝である clustertwo のプライマリがダウンした際の非同期レプリケーション接続状況を確認していきたいと思います。
対象を間違えないように…
|
1 2 3 4 5 6 7 8 9 |
MySQL localhost:3310 ssl JS > dba.stopSandboxInstance(3410) The MySQL sandbox instance on this host in 3410 will be stopped Please enter the MySQL root password for the instance 'localhost:3410': ******** Stopping MySQL instance... Instance localhost:3410 successfully stopped. |
clusterone のプライマリから接続レプリカを確認してみます。
|
1 2 3 4 5 6 |
MySQL localhost:3310 ssl SQL > SHOW REPLICAS; +------------+-----------+------+------------+--------------------------------------+ | Server_Id | Host | Port | Source_Id | Replica_UUID | +------------+-----------+------+------------+--------------------------------------+ | 2759215989 | 127.0.0.1 | 3430 | 2876111632 | 144d2c0e-37c2-11ec-a341-00163e3da7cd | +------------+-----------+------+------------+--------------------------------------+ |
clustertwo のメンバー 127.0.0.1:3430 に切り替わっています。
自動フェイルオーバが成功したようです。
clustertwo の状態を改めて確認してみます。 (一部抜粋して表示)
127.0.0.1:3430 が プライマリに昇格しているので、想定通りの挙動となりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
MySQL localhost:3430 ssl JS > cluster2=dba.getCluster('clustertwo'); <Cluster:clustertwo> MySQL localhost:3430 ssl JS > cluster2.status() { "clusterName": "clustertwo", "clusterRole": "REPLICA", "clusterSetReplicationStatus": "OK", "defaultReplicaSet": { "name": "default", "primary": "127.0.0.1:3430", (...) "topology": { "127.0.0.1:3410": { "address": "127.0.0.1:3410", "memberRole": "SECONDARY", "mode": "n/a", (...) "shellConnectError": "MySQL Error 2003: Could not open connection to '127.0.0.1:3410': Can't connect to MySQL server on '127.0.0.1:3410' (111)", "status": "(MISSING)" }, "127.0.0.1:3420": { "address": "127.0.0.1:3420", "memberRole": "SECONDARY", "mode": "R/O", (...) "status": "ONLINE", "version": "8.0.27" }, "127.0.0.1:3430": { "address": "127.0.0.1:3430", "memberRole": "PRIMARY", "mode": "R/O", (...) "status": "ONLINE", "version": "8.0.27" } }, "topologyMode": "Single-Primary" }, "domainName": "testclusterset", |
3. 停止したメンバーを復旧し、プライマリにフェイルバックさせた場合
最後にフェイルバックの挙動を確認してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
MySQL localhost:3430 ssl JS > dba.startSandboxInstance(3410) Starting MySQL instance... Instance localhost:3410 successfully started. MySQL localhost:3430 ssl JS > cluster2.setPrimaryInstance("127.0.0.1:3410") Setting instance '127.0.0.1:3410' as the primary instance of cluster 'clustertwo'... Instance '127.0.0.1:3430' was switched from PRIMARY to SECONDARY. Instance '127.0.0.1:3410' was switched from SECONDARY to PRIMARY. Instance '127.0.0.1:3420' remains SECONDARY. WARNING: The cluster internal session is not the primary member anymore. For cluster management operations please obtain a fresh cluster handle using dba.getCluster(). The instance '127.0.0.1:3410' was successfully elected as primary. |
127.0.0.1:3410 をプライマリに戻しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
MySQL localhost:3430 ssl JS > cluster2.status() { "clusterName": "clustertwo", "clusterRole": "REPLICA", "clusterSetReplicationStatus": "OK", "defaultReplicaSet": { "name": "default", "primary": "127.0.0.1:3410", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "127.0.0.1:3410": { "address": "127.0.0.1:3410", "memberRole": "PRIMARY", "mode": "R/O", (...) "status": "ONLINE", "version": "8.0.27" }, "127.0.0.1:3420": { "address": "127.0.0.1:3420", "memberRole": "SECONDARY", "mode": "R/O", (...) "status": "ONLINE", "version": "8.0.27" }, "127.0.0.1:3430": { "address": "127.0.0.1:3430", "memberRole": "SECONDARY", "mode": "R/O", (...) "status": "ONLINE", "version": "8.0.27" } }, "topologyMode": "Single-Primary" }, "domainName": "testclusterset", |
再び clusterone のプライマリから接続レプリカを確認してみます。
|
1 2 3 4 5 6 7 |
MySQL localhost:3310 ssl SQL > SHOW REPLICAS; +------------+-----------+------+------------+--------------------------------------+ | Server_Id | Host | Port | Source_Id | Replica_UUID | +------------+-----------+------+------------+--------------------------------------+ | 3259784411 | 127.0.0.1 | 3410 | 2876111632 | a433be99-37c1-11ec-9539-00163e3da7cd | +------------+-----------+------+------------+--------------------------------------+ 1 row in set (0.0002 sec) |
再度プライマリに戻った 127.0.0.1:3410 がレプリカとして切り替わっています。
おわりに
8.0.22 で追加された時点で非常に優秀な機能だった「非同期レプリケーション自動フェイルオーバ」がグループレプリケーション/InnoDB ClusterSet の枠組みで更に強化されました。
また、InnoDB ClusterSet をデプロイする過程でこの機能が自動的に設定されることも分かりました。
利用者側が意識せずとも障害時に自動的に切り替えてくれるメリットは大きく、可用性向上や運用負荷の軽減に少なからず貢献するものと考えます。
今回のように MySQL Shell を使って手軽に動作検証できますので、ぜひお試しいただければと思います。
