• MySQL と HA
• MogileFS の要求事項
• HAの例
• Flipping Sides
• データベースのバックアップ
• MogileFS と MySQL リプリケーションの スレーブ

メンテナンスページに戻る

ほとんどの MogileFS インスタンスは、メタデータの保管先として MySQL を使います。一般的に一つ以上のインスタンスを持つことは良い考えです。複数のインスタンスは、HA (高可用性)のため、スケーラビリティのためにスレーブを読むなど、に使うことができます。

MySQL と HA

高可用性のMySQLデータベースをセットアップについて不思議に思っているのであれば、自身でできる一番のことはコントラクタ(percona, openqueryなど)を雇うか、本をいくつかピックアップして読み始めることです。複数のMySQLインスタンスとMySQLリプリケーションの管理に関係する情報は たくさん あります。そのほとんどはこのドキュメントのスコープを超えます。しかしながら、MogileFSに具体的にどうやって適用できるのかについて話したいと思います。

高可用性のMySQLデータベースをセットアップについて不思議に思っているのであれば、自身でできる一番のことはコントラクタ(percona, openqueryなど)を雇うか、本をいくつかピックアップして読み始めることです。複数のMySQLインスタンスとMySQLリプリケーションの管理に関係する情報は たくさん あります。そのほとんどはこのドキュメントのスコープを超えます。しかしながら、MogileFSに具体的にどうやって適用できるのかについて話したいと思います。

MogileFS の要求事項

MogileFS は分散データストアで、多くのストレージノードと多くのトラッカーを持つことができます。しかしながら、単一の メタデータストアを持つ必要があります。それは全てのトラッカーが調和して動く場所です。ここで強調することに意味があるので繰り返します: 全ての トラッカーは 同じ データベースインスタンスを示さなければなりません。They use advisory locking to ensure they don't collide in replication, and coordinate queue processing via transactions. これ無しには、データを永久に失うかも知れません。

Two trackers will talk to the same database, and use locking features to ensure they both don't operate on the same file at the same time by accident, among many other things.

これは mogilefsでHA MySQLインスタンスを全く使えないという意味ではありません。全てのトラッカーが同じDBを示すメカニズムを確実にする限りは、正しく動くでしょう。少しの故障時間を容認することさえできます。

繰り返しますが: リプリケートされた Master/Master 構成は、MogileFSと うまく 動作しますが、それらは Active/Passive で設定されていなければなりません。

HAの例

普通は、VIP (virtual IP) とプロキシでやります。どちらもできない場合には、もっと簡単な選択肢があります。

自動 VIP

もっともよくある構成は、二つの Master/Master のリプリケートされたデータベースの間で、単純に "floating" 3つめのIPアドレスを使うことです。これは、Linux-HA プロジェクトからのハートビートまたはその他のユーティリティによって、管理されます。The writer uses a somewhat modified utility called Flipper to manually move a flip around after a DB has died or needs repair.

手動のVIP

You can use flipper, or really anything. 二つのホスト間でVIPを管理するために必要なものは、せいぜいインタフェーススクリプトとラップされたarpコマンドくらいです。幾つかの学派はDB間の自動フェイルオーバーが良いと言いますが、経験のあるDBAの多くは手動のフェイルオーバーを好みます。DBが奇妙な位置にあるか、リプリケーションが壊れた場合は、ユーザデータが時間旅行に入らないように数分間システムを壊れたままにしておくのが良いかも知れません。

プロキシ

多くのTCPプロキシとロードバランサは VIPをエミュレートするために使うことができます。トラッカーはプロキシに話し、プロキシは全ての接続をデータベースに示します。もしプロキシが最初のサーバに対して接続の失敗を検出すると、セカンダリに切り替えることができます。ここは何ができて何が動作するかの概要のため、リンクは提供しません。

データベースに対してうっかりとロードバランスをしないように とても 注意してください。TCPプロシキがダウンしたVIPから両方のデータベースに接続を送信すると、壊れたセットアップになるでしょう。

Flipping Sides

もしマスターからスレーブへVIPまたはproxyを移動するのであれば、重要なのはすばやくやることであり、切り替えた瞬間にリプリケーションが確実に追いつくようにすることです。Tools like flipper manage this for you, so be wary of any automatic failover setups you might use.

データベースのバックアップ

あなたは、バックアップに関してMySQLで利用可能な多数のドキュメントのどうようなものにでも知っている必要があります。筆者はActive/Passive Master/Masterのペアが命の恩人だと知りました。netcatとtarは、ちょっとの間止まっているデータベースをバックアップするとても速い方法です。それらはリストアもとても速いです。それから、あなたはbinlogにパッチを当てる必要があります。

メータデータDBのバックアップを取るのを覚えていることが重要です。どのようなハードウェア障害、ソフトウェアのバグ、あるいはオペレーションミスがあなたを待っているかを誰も知りません。

MogileFS と MySQL リプリケーションの スレーブ

MogileFSはリプリケートされた読み込みスレーブを読み込みクエリの負荷の拡散のために使うように設定することができます。これを書いている時点では、それ"だけ"がファイルとfile_onテーブルのクエリをスレーブに移動します。mogilefsの外部のパスのキャッシング(memcachedまたはそれ以外の場所)は、読み込みスレーブとトラッカーの追加以上に全体のパフォーマンスをもっとよくするでしょう。

スレーブはmogadmを使って設定されます

$ mogadm slave
Help for 'slave' command:
 (enter any command prefix, leaving off options, for further help)

  mogadm slave add <slave_key> [opts]                storeの利用のためのslaveノードを追加する
  mogadm slave delete <slave_key>                    storeの利用のためのslaveノードを削除する
  mogadm slave list                                  現在のslaveノードのstoreをようにする。  mogadm slave modify <slave_key> [opts]             storeの利用のためにスレーブのノードを修正する

You can discover what opts are by specifying most of the command:

$ mogadm slave add

ERROR: Missing argument 'slave_key'

Help for 'slave-add' command:

  mogadm slave add <slave_key> [opts]                storeの利用のためのslaveノードを追加する

      --dsn=s              DBI DSN はどのデータベースに接続sるうかを指定します。      --password=s         接続するためのDBIパスワード。      --username=s         接続のためのDBIユーザ名。

A --dsn は以下のようになるかも知れません。--dsn "DBI:mysql:mogiledb:host=mogiledbhost"--username and --パスワードは明確でなければなりません。

DNSが間違っている知らせを受け取ることには注意してください。トラッカーはスレーブが再び削除されるまでおかしな動きをするかも知れません。

最後に、スレーブコードが比較的若いには価値がありません。これを書いているタイミングでは、改良のためと更なるアイデアの幾つかの古い投稿されたパッチがあります。However at present it doesn't take slave replication lag into account, or have great error handling.