Fabric FAQ

  1. MySQL Fabric とは何ですか?
  2. MySQL Fabric を利用するとき、特定のストレージエンジンが必要ですか?
  3. MySQL Fabric の高可用性はどのように実現されますか?
  4. MySQL サーバーの障害をどのように検出できますか?
  5. プライマリの MySQL サーバー(マスター)に障害が発生した場合、どのような事が起きますか?
  6. フェイルオーバー発生時、アプリケーション側の対応が必要ですか?
  7. MySQL Fabric は準同期レプリケーションと一緒に動作できますか?
  8. すぐに一貫した読取りが必要な場合(最新のデータを取得する必要がある場合)どうしたら良いですか?
  9. MySQL Fabric でどのようにスケーリングを実現できますか?
  10. スケーリングは読取りと書込みの両方に適用されていますか?
  11. 全てのシャードに必要なテーブルデータを持っている場合はどうなりますか?
  12. MySQL Fabric は競合やデッドロックを引き起こしますか?
  13. データセットまたは使用量が増えシャードが大きくなり過ぎると、どのような事が発生しますか?
  14. MySQL Fabric を使用している場合、追加の待機時間が発生しますか?
  15. シャードを異なる MySQL サーバーに移動させた場合、または複数のシャードに分割した場合、アプリケーションの変更が必要ですか?
  16. MySQL Fabric ノード自体は、フォルト・トレラントですか? MySQL Fabric ノードが利用できないとどうなりますか?
  17. どのコネクタが MySQL Fabric に対応していますか?
  18. ACID に準拠したトランザクションですか?
  19. クロスシャードの統合(UNION)と結合(JOIN)ができますか?
  20. アプリケーションに対してクエリーとトランザクションのルーティングは透過的ですか?
  21. MySQL Fabric を利用する場合、サーバーは何台必要ですか?
  22. 各 MySQL サーバーでエージェントを実行する必要はありますか?
  23. MySQL Fabric と MySQL Cluster の違いは何ですか?
  24. MySQL Fabric を利用する際のライセンスは?

1. MySQL Fabric とは何ですか?

A: MySQL Fabric はサービスを提供する MySQL サーバー群が管理されているフレームワークです。拡張できるように設計されているため、時間の経過とともに異なるサービスを追加できます。現時点では高可用性(MySQL レプリケーションに基づいた)とスケールアウト(データシャーディング)を提供しています。

MySQL Fabric は MySQL Fabric ノード/プロセス(管理機能を実行)と Fabric 対応コネクタで実行されます。Fabric 対応コネクタは最適な MySQL サーバーへクエリーとトランザクションを直接ルーティングします。MySQL Fabric ノードのステートストア(MySQL データベース)には各ノードの状態とルーティング情報が含まれます。

2. MySQL Fabric を利用するとき、特定のストレージエンジンが必要ですか?

A: いいえ。MySQL Fabric で管理されている MySQL サーバーは引き続き InnoDB が利用できます。(将来的に NDB/MySQL Cluster もサポート予定です)

3. MySQL Fabric の高可用性はどのように実現されますか?

A: MySQL Fabric は一つ以上の HA グループ(各HA グループは一つ以上の MySQL サーバーを含みます)を管理します。高可用性を実現するためには、HA グループには一つのプライマリ MySQL サーバー、一つ以上のセカンダリ MySQL サーバーを含めます。グループ中のプライマリは MySQL レプリケーションのマスターであり、プライマリから各セカンダリへデータを複製します(セカンダリはレプリケーションのスレーブサーバーです)。

初期設定で MySQL Fabric 対応コネクタはプライマリへの書込みをルーティングし、利用可能なセカンダリからの読取りをロードバランスします。

プライマリ障害発生時、MySQL Fabric はセカンダリの中から一つを選んでプライマリに昇格させます。(自動的に MySQL サーバーをレプリケーションのマスターに昇格し MySQL Fabric 対応コネクタはルーティング情報を更新します)。

4. MySQL サーバーの障害をどのように検出できますか?

A: MySQL Fabric ノードにマスターのステータスをチェックするモニター機能が組み込まれています。また、プライマリに障害が発生した場合、Fabric 対応コネクタは MySQL Fabric に報告します。管理者はフェイルオーバー開始前に通知されるべき問題の数(および経過時間)を設定できます。

5. プライマリの MySQL サーバー(マスター)に障害が発生した場合、どのような事が起きますか?

A: MySQL Fabric ノードはセカンダリから新プライマリを選びます。この際、下記二つのアクションを実行します:

  • セカンダリをレプリケーションのマスターに昇格させます(他の稼働中のセカンダリは新マスターサーバーのスレーブになります)
  • ルーティング情報を更新します。結果として Fabric 対応コネクタは障害が発生したプライマリへのクエリーやトランザクションの送信を止め、代わりに新プライマリに送信します。
6. フェイルオーバー発生時、アプリケーション側の対応が必要ですか?

A: いいえ、必要ありません。フェイルオーバーはアプリケーションに対して透過的です。Fabric 対応コネクタは新サーバーのトポロジに基づいてトランザクションとクエリーのルーティングを自動的に開始します。アプリケーションはプライマリ障害発生時、新プライマリを入れ替える以前にエラーとなったトランザクション(フェイルオーバー中に実行されエラーになったトランザクション)を処理する必要がありますが、これは通常の MySQL のエラー処理と同様です。

7. MySQL Fabric は準同期レプリケーションと一緒に動作できますか?

A: 現在のバージョンでは MySQL Fabric は非同期レプリケーションを利用して HA グループを作成します。準同期レプリケーションを利用したい場合、MySQL Fabric によってレプリケーション関係が作成されてから、ユーザーが手動で設定できます。

8. すぐに一貫した読取りが必要な場合(最新のデータを取得する必要がある場合)、どうしたら良いですか?

A: プライマリ(マスター)からセカンダリ(スレーブ)へのレプリケーションは非同期のため、セカンダリからの読取りは最新のデータを取得することが保証できません。プライマリから読取りを強制するために、アプリケーションは読取りではなく読取り/書込みを接続モードプロパティで設定することができます。

9. MySQL Fabric でどのようにスケーリングを実現できますか?

A: 水平方向のスケーリングは複数の MySQL サーバーまたは HA グループ間でテーブルからデータをパーティショニング(シャーディング)することによって実現されます。この場合、各サーバーまたグループは特定テーブルの行のサブセットを含みます。

ユーザーはテーブルのカラムをシャードキーとして指定し、シャード分割の方法(HASH もしくは RANGE)も指定します。RANGE ベースのシャーディングを使用する場合、ユーザーは RANGE とシャードのマッピングを指定する必要があります。現時点では、シャーディング・ キーは数値でなければなりません。

データベースにアクセスする時、アプリケーションはシャーディング・キーを指定します。Fabric 対応コネクタは指定されたシャーディング・キーをシャードIDにマッピングして(MySQL Fabric サーバーから取得され、取得されたマッピングデータはコネクタにキャッシュされます)、クエリーまたはトランザクションを正しい MySQL サーバーへルーティングします。

HA グループ内では Fabric 対応コネクタはプライマリへ直接に書き込めます。また、全ての利用可能なセカンダリで読取りクエリーを実行できます。(プライマリで読取りクエリーを実行することも可能です)

10. スケーリングは読取りと書込みの両方に適用されていますか?

A: はい。より多くの HA グループが追加されることにより、読取りと書込みの両方をリニアにスケーリングできます。さらに、HA グループにセカンダリサーバーを追加することによって、読取りも独立でスケーリングできます。

11. 全てのシャードに必要なテーブルデータを持っている場合はどうなりますか?

A:Global Group と呼ばれる特別なグループが作成されます。その中にグローバルテーブルを保持します。全ての HA グループで参照されるデータを持ったテーブルは、グローバルテーブルとして取り扱う必要があります。グローバルテーブルは全ての書き込みがグローバルグループに送信されて、全ての HA グループに複製されます。例を挙げると、employee データベース(※)の department テーブルなどです。department テーブルの内容は少ないので、全てのサーバーに格納できます。そのデータはシャーディングされた employee テーブルのあらゆるレコードから参照されます。※employee データベースについては こちらを参照ください

同様にスキーマの変更はグローバルグループに送信され、全ての HA グループに複製されます。

12. MySQL Fabric は競合やデッドロックを引き起こしますか?

A: いいえ。一つのトランザクションは一つのシャード(+グローバルテーブル)のデータのみアクセスできます。全ての書込み処理はそのシャードの HA グループのプライマリサーバーに送信されます。つまり、特定の行への全ての書込みは同じ MySQL サーバーによって処理されるため、InnoDB の行ベースロックは通常通り動作します。

13. データセットまたは使用量が増えシャードが大きくなり過ぎた場合、どうしたら良いですか?

A: MySQL Fabric は以下の機能を提供します:

  • シャードの移動:ハイパフォーマンス・サーバーを含む新しい HA グループにシャードを移動できます。
  • シャードの分割:既存のシャードを二つ分けて、新しいシャードを新しい HA グループに保存できます。将来的には、シャード分割は異なるレベルの粒度をサポートする予定です。
14. MySQL Fabric を使用している場合、追加の待機時間が発生しますか?

A: いいえ、発生しません。ルーティングはコネクタ内で処理されるため、プロキシを介するような余分な「ホップ」を必要としません。これは、MySQL Fabric がプロキシプロセスを使用していない主な理由です。二番目の理由はプロキシがボトルネックや単一障害点になる可能性があるためです。

15. シャードを異なる MySQL サーバーに移動させた場合、または複数のシャードに分割させた場合、アプリケーションの変更が必要ですか?

A: いいえ、必要ありません。 アプリケーションはシャードキーを取り扱いますが、シャードの移動や分割によってシャードキーは変わらないためです。

シャードキーは単純に1つ以上のテーブルからのカラムの値です。行データは1つのシャードから別のシャードやサーバーへ移動してもシャードキーは変わりません。シャードキーはシャードIDにマッピングされます。(HASH もしくは RANGE ベースのマッピングを利用)シャード ID はシャード自体を表しています。

例えば既存のシャードが二つに分割された場合、その行の一部が一つシャードのシャード ID にマッピングされて、残りは他のシャード ID にマッピングされます。この分割において行のシャードキーは変更されません。

非常に重要なのはシャード ID ではなくシャードキーがアプリケーションに知られていることです。従って、サーバー群のトポロジの変更はアプリケーションに対して完全に透過的です。

16. MySQL Fabric ノード自体はフォルト・トレラントですか? MySQL Fabric ノードが利用できないとどうなりますか?

A: 現在、MySQL Fabric ノードはシングル・インスタンスのみです。プロセス障害発生時、そのマシンまたは別のマシンで再起動できます。ステートとルーティング情報は既存のステートストア(MySQL データベース)あるいは複製されたステートストアのコピーから読み取ることができます。

MySQL Fabric ノードが無効の場合でも Fabric 対応コネクタはキャッシュされたルーティングデータのコピーに基づいてクエリーとトランザクションを正しいサーバーにルーティングできます。但し、MySQL Fabric ノードが回復する前にプライマリに障害が発生した場合は自動的にフェイルオーバーできません。そのため MySQL Fabric プロセスを速やかに復旧することが重要です。

17. どのコネクタが MySQL Fabric に対応していますか?

A: 現在、PHP、Python、Java は MySQL Fabric に対応しています。また、O/R マッパーの Hibernate と Doctrine にも対応しています。今後も新しいコネクタを追加する予定です。

18. ACID に準拠したトランザクションですか?

A: はい。各トランザクションは単一の MySQL サーバーで処理されるため、InnoDB ストレージエンジンの全ての ACID 動作に対応しています。

19. クロスシャードの統合(UNION)と結合(JOIN)ができますか?

A: いいえ、現時点はできません。全てのクエリーがアクセスできるデータはシングルシャードのデータ+グローバルテーブルのデータに限られています。マルチシャードからデータを読み取る場合、アプリケーションによってデータを取得し統合する必要があります。

20. アプリケーションに対してクエリーとトランザクションのルーティングは透過的ですか?

A: ほぼ透過的です。

HA の場合、アプリケーションは操作が読取り専用なのか、または書込みも含むのか(または常に最新のデータを読み込むのか)を指定する必要があります。

シャーディングの場合、アプリケーションはシャーディング・キー(一つ以上のテーブルのカラム)を指定する必要があります。但し、これは MySQL サーバーのトポロジに依存しません。また、データがサーバー間で移動された場合でも影響を受けません。

21. MySQL Fabric を利用する場合、サーバーは何台必要ですか?

A: 開発する場合 MySQL Fabric ノードと管理されている全ての MySQL サーバーが一台のマシンで構築できます。

配置する場合、最小の HA 構成は3台以上のマシンが必要になります。

  • 2台は MySQL サーバー
  • 1台は MySQL Fabric プロセス (アプリケーションサーバーとしても利用可能)
22. 各 MySQL サーバーでエージェントを実行する必要がありますか?

A: いいえ、必要ありません。MySQL Fabric ノードのみが追加のプロセスであり、管理されている MySQL サーバーのいずれかと同じ場所に配置する必要はありません。

23. MySQL Fabric と MySQL Cluster の違いは何ですか?

A: MySQL Clusterは成熟した実績のあるソリューションです。非常に高いレベルの可用性とスケールアウト(読取りと書込みの両方に対して)を提供します。MySQL Fabric より優れている主な機能の一部は以下のとおりです:

  • 同期レプリケーション
  • 速い(自動化された)フェイルオーバー(高可用性をもたらす)
  • 透過的シャーディング
  • クロスシャード結合と外部キー
  • インメモリ、リアルタイム性能

一方、MySQL Fabric は多くのアプリケーションに適している InnoDB ストレージエンジンを継続利用できます。

24. MySQL Fabric を利用する際のライセンスは?

A: MySQL Fabric はGPL v2 のオープンソースライセンスに基づいて利用可能です。また、MySQL Enterprise Edition 若しくは MySQL Cluster Carrier Grade Edition の一部として商用ライセンスの利用もできます。