この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。
最初の記事では10年以上前から存在していた技術である「長老」を見ました。（訳注：長老編日本語訳）第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。（訳注：大人編日本語訳）この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication（グループレプリケーション）、proxy（プロキシ）、distributed storage（分散ストレージ）です。
グループレプリケーション
グループレプリケーションはOracle社がGaleraに対して出した答えです。「InnoDB cluster」という用語は、グループレプリケーションを使用するクラスターを意味します。目標は同様の機能群を提供することで、特にそのほとんどは同期機能です。
一見すると、グループレプリケーションの実装はやや洗礼されたものに見えるでしょう。この基本はGTIDレプリケーションモードです。InnoDB clusterのノードは、単一のUUIDシーケンスを共有します。レプリケーションラグを制御するために、Oracleはフロー制御層(flow control layer)を追加しました。Galeraは全ノードの一致(unanimity)を要求しますが、一方でグループレプリケーションは多数(majority)のみを要求します。使用されているプロトコルはPaxosから派生しています。（InnoDB clusterの）多数決プロトコルは、クラスターを低速ノードに対してより弾力性のあるものにします。
Galeraと同様に、フロー制御を追加するとキューが必要になります。グループレプリケーションには2つのキューがあります。certification processには1つのキューがあり、appliersには1つのキューがあります。Oracleのアプローチで興味深いのは、スロットル・メカニズム（throttling mechanism）の存在です。ノードによってフロー制御が要求されると、Galeraのように新しいトランザクションの処理を停止するのではなく、トランザクションのレートが抑制されます。これにより厳格なタイミングを要求するSLAを満たすのに役立ちます。
グループレプリケーションのロジックはGaleraと非常に似ているため「大きなトランザクション」「レイテンシ」「ホット行」という同じ制限に悩むでしょう。グループレプリケーションは最近のものです。最初のGAバージョンは5.7.17で、2016年12月からです。それは当然、いくつか最先端の機能を持っています。ここであまり引き伸ばして話をしませんが、もし興味があるならここか 、ここを読んでください。私は時間が経つにつれて、グループレプリケーションがより洗練されていくと確信しています。GaleraのSSTプロセスのような自動化も歓迎されます。
この技術は最近のものということも考えると、本番環境でグループレプリケーションを使用するPerconaの顧客はいません。
プロキシ
インテリジェントなプロキシは、これから登場するMySQL高可用性ソリューションの中でも、別の種類として見ることができるでしょう。これは厳密にはMySQLではありません。実際、このソリューションは他のソリューションを組み合わせたものです。
原則は簡単です。あなたはプロキシに接続し、プロキシは有効なMySQLサーバにあなたを誘導します。プロキシはバックエンドサーバーの状態を監視する必要があり、それらに対してアクションを実行しなければならない場合があるかもしれません。もちろん、プロキシ・レイヤーが単一障害点になってはなりません。基本のHAには2台以上のプロキシホストが必要です。 2台以上のプロキシが同時に使用される場合は、バックエンドサーバーの状態に同意する必要があります。例えば、MySQL非同期レプリケーションを使用するクラスターでは、プロキシが同じホストに書き込みトラフィックを送信していない場合には、すぐさま問題が発生します。
これを達成する方法はいくつかあります。最も簡単な解決策は、ある時点で1つのプロキシだけがアクティブなアクティブ - パッシブ設定です。プロキシホストが使用可能かどうかを判断するには、何らかのロジックが必要です。典型的な選択肢は、keepalivedやPacemakerなどのツールを使用します。
第2の選択肢は、プロキシがライターノードを識別する決定論的な方法に同意することです。例えばGaleraベースのクラスターでは、最も低いwsrep_local_indexを持つ正常なバックエンドノードをライターノードにすることができます。
最後に、プロキシ達は互いに話し合い調整することができます。そのようなアプローチは有望でしょう。単一のプロキシが監視を実行し、その結果をピアに通知することができます。また、障害が検出されたときに、クラスター上で調整されたアクションも可能になります。
現在のところ、プロキシの観点からはいくつかのオプションがあります。
- ProxySQL ：オープンソースで、MySQLプロトコルを理解し、R/W分割、クエリキャッシング、シャーディング、SQLファイアウォールなどを行うことができます。新しいアルファレベルの機能であるミラーリングは、プロキシ間通信のニーズをターゲットにしています。
- MaxScale：もはや完全にオープンソースではなく（BSL）、MySQLプロトコルを理解しています。R/W分割、シャーディング、binlogサービス、SQLファイアウォールなどが可能です。
- MySQL Router ：MySQL Routerは、InnoDB cluster（グループレプリケーション）用にOracleによって開発されたオープンソースプロキシです。これはMySQLプロトコルを理解しており、新しいXプロトコルもサポートしています。R/W分割ができます。
- HAProxy：HAProxyは一般的なオープンソースのTCPレベルのプロキシです。それはMySQLプロトコルを理解していません。ノードの状態を把握するために、HTTPタイプ要求に応答するヘルパースクリプトが必要です。
これらのオープンソースプロキシには、TungstenとScaleArcという2つのよく知られた商用のプロキシライクなソリューションがあります。これらの技術はいずれも成熟しており、年齢や牽引力の面では「赤ちゃん」ではありません。さらに、ハードウェアベースのロードバランサソリューションも数多くあります。
MySQLの高可用性におけるプロキシの重要性により、PerconaはPercona XtraDB Clusterの最新リリースにProxySQLを含めるようになりました。ProxySQLのメンテナであるRenéCannaòと共同で、ProxySQLにPercona XtraDB Clusterの状態を知らせる機能が追加されました。
プロキシはすでに多くの場合、MySQLの高可用性ソリューションに導入されています。多くの場合、プロキシはロード・バランシング・タイプの作業のみを行っています。私たちは、R/W分割やシャーディングなど、より高度なもののためにプロキシを使用してデプロイメントを開始します。
分散ストレージ
分散ストレージを使用したレプリケーション設定
このMySQL高可用性ソリューションは、私が興味を持っているプロジェクトです。「赤ちゃん」よりも 「胎児」であると言うのは公正でしょう。なぜなら私は本番環境でこれを使用している人は誰も知らないからです。このソリューションは、より強力な共有ストレージのアプローチとして見ることができます。
最も簡単なソリューションでは、3ノードのCephクラスターが必要です。ノードはMySQLも実行し、このdatadirはCeph RBDブロックデバイスです。Cephのデータは自動的に複数のホストに複製されます。この組み込みのデータレプリケーションは、ソリューションの重要なコンポーネントです。また、Ceph RBDはスナップショットとクローンをサポートしています。クローンとは、ストレージに関して変更されたデータ（デルタ）のみを消費するデータセット全体のコピーです。私たちの3つのMySQLサーバーは、データセットの3つの完全コピーを使用するのではなく、1つのフルコピーと2つのデルタを使用します。時間が経つと、デルタも大きくなります。それらが大きすぎる場合は、新しいスナップショットとクローンを生成して1日目に戻すことができます。新しいスナップショットとクローンの生成には数秒かかり、MySQLを停止する必要はありません。
分散ストレージのアプローチで理解しやすい使用例は、非常に大きなデータセット上の読み取り集約型のワークロードです。セットアップでは多くの書き込みを処理できます。書き込み負荷が高いほど、スナップショットのリフレッシュ頻度が高くなります。10 TBのデータセットのスナップショットをリフレッシュするには、1 GBのデータセットの場合よりも時間がかかるということを覚えておいてください。
そのため、私はCephで動作するPercona XtraDB Cluster用のSSTスクリプトを書きました。ここのブログにスクリプトについて書いています。また、マスタースナップショットからスレーブをプロビジョニングできるCephスナップショット/クローンのバックアップスクリプトを書きました。近い将来にこのCephバックアップスクリプトを使用する方法についてブログで説明します。
もう少し分散ストレージについて話します。複数のMySQLインスタンスは、同じデータページを使用する可能性があります。CephはInnoDBページの分散オブジェクトストアとしての使用になるだろうと思っています。これにより、オープンソースのAuroraのようなデータベースを構築することが出来るでしょう。GaleraやGroup Replicationと組み合わせれば、データセットの単一コピーを共有する高可用性MySQLクラスターを持つことができるでしょう。
私はCeph/Radosのサポートを追加するために、MySQL（実際にはPercona Server for MySQL 5.7）に変更を始めました。RadosはCephのオブジェクトストアプロトコルです。これを機能させるためにはまだ多くの努力が必要です。私の主な仕事は開発ではないので、進歩は遅いです。私の仕事はここで見つけることができます。ソースはうまくコンパイルされますが、MySQLは完全には起動しません。上手く動作しないところでデバッグする必要があります。
MySQLに機能を追加することは、MySQLの内部を学ぶ素晴らしい方法です。このプロジェクトに興味があれば、いかなる助けでも本当に感謝します。
結論
このシリーズの3つの記事では、2017年の高可用性ソリューションの展望について取り上げました。最初は古い製品に焦点を当てています。「長老」は、レプリケーション、共有ストレージ、NDBで構成されました。 2番目の記事では、GaleraとRDS Auroraという、より最近のソリューションを扱っています。シリーズの終わりは現在の記事で、MySQLの高可用性ソリューションとしてやがてやって来る可能性があるものを見ました。
このシリーズの主な目的は、MySQLのデプロイを計画しやすくすることです。より良い効率的なソリューションを得るためのヒントやポインターとして使用できることを願っています。
