8.0.27新機能:レプリカの非同期レプリケーション自動フェイルオーバを InnoDB ClusterSet で試す

MySQL 8.0
この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

はじめに

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

公式リファレンスマニュアルは以下になります。

MySQL :: MySQL 8.0 Reference Manual :: 17.4.9 Switching Sources and Replicas with Asynchronous Connection Failover

今回追加された機能と、これまでの機能と何が異なるか、についてまずは簡単にご紹介します。

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 を用います。

MySQL :: MySQL 8.0 Reference Manual :: 13.4.2.12 Functions which Configure the Source List

8.0.23 での機能拡張

次のリリースで、ソースDB がグループレプリケーションだった場合における機能拡張がなされました。

グループレプリケーションのプライマリメンバーをソースDBとして、別のMySQLインスタンスへ非同期レプリケーションを行っている構成において、
プライマリがフェイルオーバし、別のセカンダリが新たなプライマリに昇格した際、既存の非同期レプリケーションも、新プライマリへと接続フェイルオーバするという機能になります。
また、その後元のプライマリにフェイルバックさせた場合も、非同期レプリケーション接続は追従して自動的に接続し直されます。

設定方法を簡単に紹介します。

  1. ソースとなるグループレプリケーション側にて

    • レプリケーション用のユーザーはパフォーマンススキーマへのSELECT権限が必要となるため、事前に付与しておきます。

    • ソースとなるグループレプリケーションの group_replication_group_name を確認しておきます。

  2. レプリカ側にて

    • 事前に SOURCE_CONNECTION_AUTO_FAILOVER=1 をセットした非同期レプリケーション用のチャネルを CHANGE REPLICATION SOURCE TO で設定します。

    • asynchronous_connection_failover_add_managed UDF を用いて、接続フェイルオーバ管理対象グループの設定を行います。

    • 正しく設定されている場合、mysql.replication_asynchronous_connection_failover_managed テーブルで確認することが出来ます。

  3. 非同期レプリケーションを開始します。

    レプリケーション接続が成功しプライマリからグループメンバーの情報を取得し、フェイルオーバ候補のリストが自動更新されます。

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で変更を行います。

MySQL :: MySQL 8.0 Reference Manual :: 13.4.3.7 Functions to Set and Reset Group Replication Member Actions

ここで、すでにご存じの方はピンときたかもしれませんが、同じく 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 ユーザーのパスワード設定が促されますが、全てのインスタンスで統一しておきます。

2. クラスタセットの作成

マニュアル通り testclusterset という名前のクラスタセットを作成します。(任意の名前で構いませんが)

クラスタセットの状態を以下のAPIコマンドで確認することが出来ます。

3. レプリカクラスタの作成

新しいインスタンスを追加で作成し、そこに先ほどの clusterone を元にレプリカクラスタ(clustertwo)を作成します。

無事レプリカクラスタが作成されました。
Configuring ClusterSet managed replication channel... のメッセージがある通り、この時点でプライマリクラスタである clusterone とのレプリケーション設定が構成されたようです。

続けてレプリカクラスタのメンバー追加を行います。

クラスタセットの状態確認で、extended オプションを有効化すると、クラスタセット全体の詳細情報を取得することが出来ました。

InnoCB ClusterSet における非同期レプリケーションおよび自動フェイルオーバ機能の確認

1. 状態確認

クラスタセットが完成した時点での、ソース側(clusterone) プライマリに接続されたレプリカを確認してみます。

想定通り、clustertwo のプライマリ(127.0.0.1:3410)がレプリカとして接続されています。

レプリカ側でレプリケーション詳細情報(抜粋)を確認してみます。

clusterset_replication というチャネル名で構成されています。
I/Oスレッド、SQLスレッド共に正常に動作しています。

フェイルオーバ候補リストを確認してみます。

clusterone のグループメンバーが自動的に登録されています。

SOURCE_CONNECTION_AUTO_FAILOVER も有効化されていることが分かります。

リファレンスマニュアルの記載にありますが、非同期レプリケーションチャネル設定済みのノードをクローンしてグループレプリケーションを構成する場合、設定がそのまま複製されるので手動で設定する必要はないようです。
また、グループに新たに追加したメンバーに対しても、設定が自動的に伝搬される(後から SOURCE_CONNECTION_AUTO_FAILOVER=0 で非同期レプリケーションフェイルオーバを無効化した場合でもそれが伝搬される)仕組みになっています。

クローン機能とグループレプリケーションを生かしたシンプルで効率の良い方法と言えますね。

また、Deploying InnoDB ClusterSet のページにも明記されていますが、レプリカクラスタを作成すると API が自動で各種設定を実施します。

例えば、レプリカクラスタはプライマリでも read_only super_read_only がONになります。
また、セカンダリが再起動してしまったときに非同期レプリケーションチャネルが自動で開始しないように skip_replica_start に設定されるのが特徴的です。

2. レプリカになっているプライマリメンバーの停止時

早速、今回の肝である clustertwo のプライマリがダウンした際の非同期レプリケーション接続状況を確認していきたいと思います。

対象を間違えないように…

clusterone のプライマリから接続レプリカを確認してみます。

clustertwo のメンバー 127.0.0.1:3430 に切り替わっています。
自動フェイルオーバが成功したようです。

clustertwo の状態を改めて確認してみます。 (一部抜粋して表示)
127.0.0.1:3430 が プライマリに昇格しているので、想定通りの挙動となりました。

3. 停止したメンバーを復旧し、プライマリにフェイルバックさせた場合

最後にフェイルバックの挙動を確認してみます。

127.0.0.1:3410 をプライマリに戻しました。

再び clusterone のプライマリから接続レプリカを確認してみます。

再度プライマリに戻った 127.0.0.1:3410 がレプリカとして切り替わっています。

おわりに

8.0.22 で追加された時点で非常に優秀な機能だった「非同期レプリケーション自動フェイルオーバ」がグループレプリケーション/InnoDB ClusterSet の枠組みで更に強化されました。

また、InnoDB ClusterSet をデプロイする過程でこの機能が自動的に設定されることも分かりました。

利用者側が意識せずとも障害時に自動的に切り替えてくれるメリットは大きく、可用性向上や運用負荷の軽減に少なからず貢献するものと考えます。

今回のように MySQL Shell を使って手軽に動作検証できますので、ぜひお試しいただければと思います。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次