MySQLの高可用性構成の展望2017年版

このブログでは、さまざまなMySQL高可用性オプションについて考察します。

ダイナミックなMySQLエコシステムは、MySQLを中心に構築された多くの技術を急速に進化させています。これは、MySQLの高可用性（HA）の側面に関連する技術に特に当てはまるでしょう。 私が2009年にPerconaに入社したとき、こういったHAの技術のいくつかは非常に人気がありましたが、それ以来ほとんどは忘れられています。その同じ期間で、新しい技術が登場しました。読者にいくつかの視点を提供しながら、出来ればより良い選択をする助けになるように、2017年のMySQL HAの展望をレビューしようと思います。このレビューは3つのパートに分かれています。最初のパート（この記事）は、長年に渡って存在していた技術、すなわちthe elders(長老たち)を扱います。2つ目のパートでは、今日大変人気のある技術、すなわちthe adults(大人達)に焦点を当てます。最後のパートでは、来たる数年後にどの技術が普及するかを予想してみたいと思います。すなわち、ここではthe babies(赤ちゃん達)を扱います 。

簡単な注意書きになりますが、私は最もよく理解している技術について説明しています。他の多くのソリューションがここには記載されていない可能性がありますが、私がほとんどまたは全く使用したことのない技術については話すことは出来ません。リレーショナルデータベースシステム(RDS)関連の技術を除いて、対象となる全ての技術はオープンソースです。この記事の対象読者は、MySQLに比較的新参である方です。

The Elders(長老たち)

the elders(長老たち）グループの技術を定義しましょう。これらは、過去10年間MySQLに携わっていた誰もが認識のある技術のはずです。私はこのグループを「古典」と呼んでいたかもしれません。このグループには以下の技術が含まれています：

• レプリケーション
• 共有ストレージ
• NDB Cluster

以下のセクションで、これらの技術をレビューしていきます。

レプリケーション

シンプルなレプリケーショントポロジー

MySQLのレプリケーションは非常によく知られています。MySQLの幅広い採用の背景にある主な機能の1つです。レプリケーションはほぼ全ての場所で使用されます。その理由は以下の通り、数多くあります。

• レプリケーションはセットアップが簡単です。 MySQLサーバーにスレーブを追加するための利用可能なハウツーガイドとスクリプトが多くあります。Amazon RDSでは、スレーブの追加は単に数クリックするだけなのです。
• スレーブを使用すると、読み取りを簡単にスケールすることができます 。スレーブはアクセス可能であり、読み取りに使用することができます。これは、MySQLデータベースを拡大する最も一般的な方法です。
• スレーブはマスターにほとんど影響を与えません 。 追加されたネットワークトラフィックを除いて、スレーブの存在はマスターのパフォーマンスに大きな影響を与えません。
• MySQLは非常に良く知られています。 ここに驚きはないでしょう。
• フェールオーバーに使用されます。 マスターが停止したら、スレーブを昇格させて新しいマスターとして使ってください。
• バックアップに使用されます。バックアップによってマスターに負荷を掛けたくないのであれば、その負荷はスレーブに逃しましょう。

もちろん、レプリケーションにもいくつかの問題があります。

• レプリケーションは遅れる可能性があります。レプリケーションはかつてシングルスレッドでした。これは、並行処理を扱う1つのマスターが1つのスレーブを容易に上回る可能性があることを意味します。MySQL 5.6とMariaDB 10.0では、スレーブに対していくつかの並列処理を導入しました。新しいバージョンでは、かつてのスレーブよりも現在のスレーブは何倍も速くなるという段階までより改善しています。
• スレーブはマスターと異なる可能性があります。マスター上のデータを変更する場合、スレーブは全く同じ更新を実行しなければいけません。これは簡単ですが、ステートメントベースのレプリケーションでは、更新が非決定的になり得る場合が多くあります。彼らは多くの問題を修正し、そして行ベースのレプリケーションの導入はもう一つの大きな前進でした。それでも、あなたがスレーブに直接書き込んでしまえば、自ら災難を招いている事になります。read_only設定はありますが、MySQLユーザーが 「SUPER」の特権を持っている場合は単に無視されます。そのため、現在は「super_read_only」設定があります。この問題を解決するために、Perconaツールキットのpt-table-checksumやpt-table-syncなどのツールが存在します。
• レプリケーションはマスターに影響を与える可能性があります。 私は、スレーブの存在はマスターには影響しないと上述しましたが、ロギングの変更はより問題を含むものになります。最も一般的な問題は、ステートメントベースのレプリケーションによるauto_increment値のInnoDBテーブルレベルロックです。一度に1つのスレッドだけが新しい行を挿入可能です。行ベースのレプリケーションおよび適切に設定されている構成では、この問題を回避できます。
• データは失われる可能性があります。レプリケーションは非同期です。これは、スレーブがまだ更新を受け取っていないにも関わらず、マスターがcommit文の後に "done"と返答することを意味します。マスターがクラッシュした場合、一部のトランザクションが失われる可能性があるでしょう。

古い技術ではありますが、レプリケーションに関して多くの取り組みが行われてきています。5.0.xのレプリケーション実装からほど遠いものでしょう。恐らく不完全ではあるものの、以下にレプリケーションの進化リストがあります。

• 行ベースのレプリケーション （5.1以降）。行のバイナリ内部表現がSQL文の代わりに送信されます。これにより、スレーブの相違に対してレプリケーションがより堅牢になります。
• グローバルトランザクションID （5.6以降）。トランザクションは一意に識別されます。binlogファイルとオフセットを知らなくてもレプリケーションをセットアップできます。
• チェックサム （5.6以降）。Binlogイベントには、整合性を検証するためのチェックサム値があります。
• 準同期レプリケーション（5.5以降）。スレーブによるイベントの受信をマスターに認識させるためのレプリケーションプロトコルの追加。これは、マスターがクラッシュしたときにデータ消失を回避するのに役立ちます。
• マルチソースレプリケーション （5.7以降）。1つのスレーブが1つ以上のマスターを持つことを可能にします。
• マルチスレッドレプリケーション （5.6以降）。スレーブが複数のスレッドを使用できるようにします。これはスレーブの遅れを制限するのに役立ちます。

レプリケーションの管理は面倒な仕事です。コミュニティは、レプリケーションを管理するための多くのツールを書いています。

• MMM 古いPerlツールでかつては大変人気がありましたが、多くの問題がありました。今ではめったに使われません。
• MHA レプリケーションを管理する最も一般的なツールです。データを失うことなくレプリケーションを再構成することに優れており、フェールオーバーの処理に対して優れています。これはシンプルでもあります。普及しているのも不思議ではありません。
• PRM MMMを置き換えるために開発されたPacemakerベースのソリューション。フェールオーバーは非常に優れていますが、レプリケーションを再構成する際のMHAほど良くはありません。Pacemakerのおかげで、これもかなり複雑です。あまり使われていません。
• Orchestrator 新しいクールなツール。複雑なトポロジーを管理することが可能で、トポロジーを監視および制御するための優れたWebベースのインターフェイスを備えています。

共有ストレージ

シンプルな共有ストレージトポロジー

私が10年前にMySQL社で働いていた時、共有ストレージHAの構成は非常に一般的でした。共有ストレージHAクラスタは、2つのうちの1つのサーバで、1つのデータベースファイルのコピーを使用します。一方のサーバーはアクティブで、他方のサーバーはパッシブです。共有されるために、データベースファイルは両方のサーバーでマウントできるデバイスに存在します。デバイスは物理的（SANのようなもの)、もしくは論理的（Linux DRBDデバイスのようなもの）でもかまいません。さらに、リソースやフェールオーバーを処理するには、クラスタマネージャ（Pacemakerなど）が必要です。このソリューションは、トランザクションを失うことなくフェールオーバーを可能にするため、非常に一般的です。

この構成の主な欠点は、アイドル状態の待機サーバーが必要であることです。スタンバイサーバーは、MySQLサーバーを引き継ぐ準備ができている必要があるため、他に仕事を割り当てることは出来ません。共有ストレージソリューションも、明らかにファイルレベルの破損に対して回復力がありません（しかし、その状況は例外的です）。最後に、クラウドベースの環境ではうまく動作しません。

現在、新しく配備された共有ストレージHAの構成はまれでしょう。私が昨年遭遇した唯一のものは、サポートが必要な古い実装か、既存の企業テクノロジースタックのために導入された新しい構成でした。それは技術が持つ人気の喪失について教えてくれるはずです。

NDB Cluster

シンプルなNDB Clusterトポロジー

NDB Clusterは、長年にわたって使用されてきた分散クラスタリングソリューションです。私は個人的に2008年にこの技術を使い始めました。NDB Clusterには、3種類のノードがあります。これは、SQLノード、管理ノード、データノードです。フルHAクラスタには、最低4つのノードが必要です。

NDB Clusterは分散された特徴のために、汎用データベースではありません。適切なワークロードには、並外れて良いです。不適切なワークロードの場合、それは悲惨です。NDB Clusterの適切なワークロードは、並行性が高く、プライマリキー指向の小さなトランザクションの割合が高いものでしょう。NDB Clusterで1秒あたりのトランザクションが100万に達することは何も例外ではありません。

その対極にあるもので、NDB Clusterの貧弱なワークロードは、スター型スキーマに対するシングルスレッドのレポートクエリです。私は、レポートクエリのネットワーク時間が20分以上に達した極端なケースをいくつか見てきました。

NDB Cluterは改善され、まだ改良されていますが、NDB Clusterの使用はニッチタイプのアプリケーションに向けて推進されています。全体として、この技術は立場を失われつつあり、現在は通信事業者やオンラインゲームアプリケーションに使用されています。