スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MySQLのデュアルソース(デュアルマスタ)について

はじめに

MySQLを使用しているユーザの多くは「レプリケーション」機能を使用されているのではないかと思います。同機能を利用すると様々なレプリケーション構成(トポロジー)を組むことができます。

主なトポロジーとしては以下のようなものが挙げられます。勿論、別々のトポロジーを組み合わせるケースもあります。

  • 通常のソース-レプリカ構成(1台のソース+複数台のレプリカ)
  • マルチソースレプリケーション構成(複数台のソース+1台のレプリカ)
  • グループレプリケーション構成(複数台のソース)
  • 多段レプリケーション構成(ソース+子レプリカ+孫レプリカ)

そうした中で少しマイナーなトポロジーとして「デュアルソース(デュアルマスタ)構成」があります。これは2台のMySQLがお互いに「ソース」且つ「レプリカ」として同期し合う構成です。

※ 通常の非同期レプリケーションを使った構成の他、「Galera Clusterを使ったデュアルソース構成」もあります

今回はこの珍しい構成をテーマとして取り上げたいと思います。

デュアルソース構成のメリット・デメリット

デュアルソース構成を組んだ場合のメリットとしては以下のような点が挙げられます。

【メリット】

  • 通常のソース・レプリカ構成であればソースは1台のみで、なおかつレプリカは通常read_onlyが有効なため、ソースがダウンすると更新可能なMySQLが無くなります。しかし、デュアルソースの場合は更新可能なソースが2台あるため片方がダウンしても継続が可能です。
  • 利用するのは通常の非同期レプリケーション機能であるため、特別な知識が必要ない
  • 更新クエリを2台のソースに分散させることも可能

一方、以下のようなデメリットも存在します。

【デメリット】

  • 更新クエリの内容によっては、両方のソースで更新が重複してしまいレプリケーションが壊れてしまう(不整合が発生する)
     → とくにauto_incrementの挙動に注意が必要(auto_increment_incrementauto_increment_offset を利用)
  • アクティブ-スタンバイ(詳細は後述)の構成にすれば上記の更新重複は回避できるが、メリットがいくつか失われる

結論としては、デュアルソース構成は少し使うのにはコツが要ります。そのため、正直一般的な構成とは言えず、実際に本番導入されているケースも少ないかと思います。

NDB Clusterを使用したデュアルソース構成

一般的には通常のMySQL Serverを使ってデュアルソース構成を組みますが、MySQL NDB Clusterを使って構築することも可能です。

もし2ノード構成のMySQL NDB Clusterを使ってみたい場合、dbdeployerを使って簡単に検証することができます。なお、今回は dbdeployer ver 1.52.0 を使用しています。

.tar.gzパッケージは公式ページからダウンロードしてください

MySQL NDB Clusterを使った場合、更新クエリの分散処理もサポートされているため動作に不具合が出る可能性は低くなります。MySQL NDB ClusterはMySQL Serverとは異なる特徴を持つ製品であり、2ノードで構成することは一般的ではありませんが、試してみても良いかもしれません。

デュアルソース構成と自動フェイルオーバ

もし、デュアルソース環境を利用する場合に便利な機能があります。それは、以前別の記事でも取り上げた「接続フェイルオーバ」機能です。

ここでは、以下のような構成を想定しています。

  • ソースが2台存在し、互いにソース・レプリカとなるレプリケーションを組んでいる(レプリA)
  • 通常時はDB①(Active)に対してのみ更新クエリを実行し、DB①がダウンしている場合にDB②(Standby)を使用する
  • DB①をソースとしてDB③がレプリカとして存在し(レプリB)、参照クエリはDB③に対して実行する

この構成の場合、DB①がダウンもしくはレプリBのNWが切断された場合、通常であればDB③はエラーのまま放置され、データの整合性も保たれなくなります。
しかし、フェイルオーバ機能を使えばDB①がダウンしてもDB③はソースを自動的にDB②に切り替えてくれるため、整合性は保たれることが期待されます。

再び、dbdeployerを使って、上記の挙動を確認してみましょう。

※ MASTER_RETRY_COUNTは「ソースへの切断を検知した後に接続をリトライする回数」で、MASTER_CONNECT_RETRYはリトライする間隔です。デフォルトではこのリトライ回数が60日間と非常に長いため、設定を変更することを推奨します

上記でフェイルオーバーの設定は完了です。それでは早速Node1を停止して、フェイルオーバーを実施してみましょう。

おわりに

実際の本番環境でデュアルソース構成を採用するケースは少ないかもしれませんが、このような構成が存在するという知識を覚えておくだけでも運用の選択肢は増えるかと思います。
MySQLを導入したい環境のサーバ台数や要件に合わせて、最善の構成を選択できるよう気を付けましょう。


MySQL

 

Return Top