スマートスタイル TECH BLOG

データベース&クラウド技術情報

非同期レプリケーション接続フェイルオーバについて

2020/10/19 に、待望の MySQL Server 8.0.22 がGAしました。

本リリースでも様々な興味深い機能が追加されていますので、今回は、MySQL Server 8.0.22に含まれる気になる新機能についてご紹介します。

新機能や変更点について網羅的に知りたいという場合は、公式のリリースノートをご確認頂ければと思います。

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-22.html

なお、弊社ではMySQLを始めとした製品のリリース情報を和訳しサイトに公開していますので、よろしければ合わせてご確認ください。

https://www.s-style.co.jp/mysql_news/mysql/mysql-8-0-22-ga版(リリース日:2020年10月19日).html

非同期レプリケーション接続フェイルオーバについて

リリースノートを眺めていると、以下の内容がサラッと記載されています。

You can use MySQL Server’s new asynchronous connection failover mechanism to automatically establish an asynchronous (source to replica) replication connection to a new source after the existing connection from a replica to its source fails. The connection fails over if the replication I/O thread stops due to the source stopping or due to a network failure. The asynchronous connection failover mechanism can be used to keep a replica synchronized with multiple MySQL servers or groups of servers that share data, including asynchronous replication from servers where Group Replication is in use. To activate asynchronous connection failover for a replication channel set SOURCE_CONNECTION_AUTO_FAILOVER=1 on the CHANGE MASTER TO statement for the channel, and set up a source list for the channel using the asynchronous_connection_failover_add_source and asynchronous_connection_failover_delete_source UDFs.

MariaDB MaxScaleや、 Orchestratorでは フェイルオーバ/スイッチオーバの一環としてレプリカの接続先のソースを正常なインスタンスに切り替えるという動作が含まれています。
上記のような機能が、この度ネイティブな機能として実装されたようです。

WL#12649 で本機能の詳細な説明を確認できますが、以下の記載の通り、本機能はMySQL InnoDB Cluster(MIC)をソースとした構成を意識した機能となっています。

MOTIVATION
The main driver of this worklog is to make deployment fault-tolerant of sender failure by automating the process of re-establishment of an asynchronous replication connection to another sender of sender list. The sender server can be deployed across wide-area in different location, to improve the Disaster Recovery (DR) to even failures of whole data center. This will also be true for Innodb cluster as the sender can also be a member of an Innodb cluster. When Innodb Cluster was introduced it created a fault-tolerant system where redundant components could be removed automatically and the system continued to operate as expected. This work will further improve fault-tolerance of Innodb cluster to failures of whole data center, by creating fault-tolerant replica cluster across wide-area in different location.

MICをソース(=Sender)としたリードレプリカ(=Receiver)を構築した際に、MICの各ノードをフェイルオーバ候補として登録しておくだけで、非同期レプリカの手動ソース切り替えを必要とせずサービスを継続する事ができます。

同機能の要件

https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-connection-failover.html

本機能を使用するための要件は以下のとおりです。

  • ソース、レプリカともにgtid_mode = ONである
  • レプリカの設定において、CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1 が設定されている
  • すべてのソース候補となるデータベースへ、チャネルごとに同じユーザ/パスワードで接続できる
  • START REPLICA実行時にパスワードを指定する方法では利用できない(CHANGE MASTER TO時に指定する)

GTIDが有効であれば、利用に際して大きなハードルはありません。

機能検証

今回はdbdeployerを使用して検証を行いました。

手元で検証を行われる場合は、dbdeployerとMySQL 8.0.22 の必要なパッケージの準備をお願いいたします。

dbdeployerのセットアップ

Group Replication(GR) + Async Replicationのセットアップ

MICをソースとした場合の非同期レプリカの動作を確認します。

注意点として、本機能はCHANGE MASTER TO に指定する MASTER_CONNECT_RETRY の間隔で、 MASTER_RETRY_COUNT 回数の再接続を施行しても成功しなかった時にトリガされます。
デフォルトでは、MASTER_CONNECT_RETRY60(秒)MASTER_RETRY_COUNT86400(回) となっており、60日間フェイルオーバが発生しませんので、適宜オプションを変更する必要があります。
今回は1秒×5回(=5s)でフェイルオーバする設定としましたが、本番ではレプリカで遅延を許容できる値に調整する必要があります。
そして、本機能を有効化するためには SOURCE_CONNECTION_AUTO_FAILOVER = 1 を指定する必要があります。
SOURCE_CONNECTION_AUTO_FAILOVER はレプリケーション(I/Oスレッド)が実行中であっても設定が即時反映されますので、機能のON/OFFは気軽に切り替えられます。

次にレプリカ上でソースとなるインスタンスの候補リストを作成します。
ソース候補の追加と削除は、以下のUDFを使用して行います。

https://dev.mysql.com/doc/refman/8.0/en/replication-functions-source-list.html

  • asynchronous_connection_failover_add_source(channel, host, port, network_namespace, weight)
  • asynchronous_connection_failover_delete_source(channel, host, port, network_namespace)

channel, host, port は既知のレプリケーションパラメータと同義です。
channel は必須ではありません。
network_namespace はこちらも8.0.22から導入された機能となり、コンテナ・仮想環境で動作するmysqldを想定した物理NICとは異なるネットワーク名前空間上の通信を制御するためのものです。
物理NICに設定されたネットワークを利用する場合は空で問題ありません。
weight はフェイルオーバ先の優先順位をつけるためのものであり、同じweightを持つソースはランダムで選択されます。

今回はGroup Replicationに所属するすべてのインスタンスを指定しました。
また、1インスタンスのみweightを低めに設定しました。

追加したソース候補は mysql.replication_asynchronous_connection_failover に格納されています。

それでは現在アクティブなソースであるMIC(node1)のインスタンスを停止します。

レプリカのエラーログには以下の出力が確認できました。

同機能がトリガされたという明示的なメッセージは見当たりませんが、5回リトライした後通常のCHANGE MASTER/START REPLICAを実行した時とほぼ同じ出力が確認できました。
※ソースが切り替わった都合上MY-010549のメッセージが出力されています。

レプリケーションも特に問題なく継続されました。

実運用ではMIC等のノード毎にホスト上で実行するジョブ等を分けていたり、運用上の役割をもたせているなどの都合から、復旧後はフェイルバックしたいという事もよくあります。
再度MIC(node1)を起動することで、自動的にレプリケーションもフェイルバックするか試してみましたが、結論としてはフェイルバックはしませんでした。

これについてはドキュメントにもフェイルバックは行われない旨が明記されています。

Once the replica has succeeded in making a connection, it does not change the connection unless the new source stops or there is a network failure. This is the case even if the source that became unavailable and triggered the connection change becomes available again and has a higher priority setting.

ただしMIC(node1)が起動していれば、現在の接続先であるMIC(node2)を停止することで、MIC(node3)のweightよりもMIC(node1)のweightが高いため、フェイルバックされるはずです。
ここで気をつけたいのが、以下のドキュメントの記載に当てはまる場合、一度停止したサーバではレプリケーションユーザの認証情報のキャッシュが消えてしまい、認証に失敗します。

https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html

重要
caching_sha2_passwordプラグインで 認証されるレプリケーションユーザーアカウントを使用してソースに接続するには、 17.3.1項「暗号化された接続を使用するためのレプリケーションの設定」の説明に従って安全な接続を 設定するか、暗号化されていない接続を有効にしてパスワードをサポートする必要があります。
RSAキーペアを使用して交換します。 caching_sha2_password認証プラグインは、MySQL 8.0から作成された新規ユーザーのデフォルトです(詳細については、参照 セクション6.4.1.2を、「キャッシュSHA-2のPluggable Authentication」)。作成またはレプリケーションに使用するユーザーアカウントの場合(MASTER_USER オプション)はこの認証プラグインを使用し、安全な接続を使用していない場合、接続を成功させるにはRSAキーペアベースのパスワード交換を有効にする必要があります。

非SSLレプリケーション接続(デフォルト)をご利用の場合は、レプリケーションユーザの認証プラグインをmysql_native_passwordとすることをおすすめします。

MIC(node2)を停止すると、weightの高いMIC(node1)にフェイルオーバしました。

このように、暗黙的に意図したソースへフェイルオーバ、フェイルバックを行いたい場合は、weightを活用するとよいかと思います。

なおマニュアルが介在するのであれば、今まで通りレプリカを停止後 CHANGE MASTER TO MASTER_HOST = <フェイルバック先 IP> を実行しレプリカを起動してソースの切り替えをすることをおすすめします。

レプリカの複製

ドキュメントを見ると、Remote Cloneで作成したレプリカにはDONERのSOURCE_CONNECTION_AUTO_FAILOVERとmysql.replication_asynchronous_connection_failoverが引き継がれるようです。

The setting for the SOURCE_CONNECTION_AUTO_FAILOVER option of the CHANGE MASTER TO statement, and the source list, are transferred to a clone of the replica during a remote cloning operation.

Clone Pluginをインストールし、既存のレプリカをDONERとして新しいレプリカを作成します。
Clone Pluginの使用方法は弊社の記事を参考にして頂ければ幸いです。

確かに設定が引き継がれているようです。

MIC(node1)を停止すると、正常にフェイルオーバが行われました。

基本的にはシンプルな機能ということもあり、特に気になることもなく非常に安定感を感じました。

様々なトポロジでの利用

機能自体は特にMICに限定されたものでは無く、レプリカ側のバージョンが8.0.22であれば利用可能であるため、Galera ClusterやDRBDをソースとした環境、多段レプリケーションで中間マスタが停止した場合の保険として利用する事等、幅広い用途が考えられます。

Galera Cluster + Async Replica

Async Replica(Source + 2 Replica)

フェイルオーバ先の第一候補でないレプリカのソース候補を指定しておくことでトポロジが保たれます。

Multi Source Replication

例えばマルチソースレプリケーションを使用している環境ではチャネル毎にソース候補を登録しておくことで冗長性が保たれます。
例では対向環境におけるF/O先のレプリカをソース候補とし、レプリカはマルチソースレプリケーションを使用しています。

所感

従来からのMySQLの強みであるレプリケーション機能がより自律的になり、Clone Pluginと合わせて使用することで、
マルチサイト、マルチリージョン、マルチクラウドでの運用の敷居が低くなるように思いました。

また、小規模な環境でも本機能を導入することで、障害発生時にレプリカのことを気にせずにソースの復旧に注力できるのではないでしょうか。

今後もMySQLの高可用性界隈の機能に注目していきたいと思います!


MySQL

 

Return Top