web-dev-qa-db-ja.com

MySQLレプリケーションと高可用性

これはこのサイトで質問するのにあまり良い質問ではないかもしれませんが、正しい道に進むためにいくつかのヘルプ/ヒントが本当に必要です。

マスター-マスターレプリケーションモードの2つのMySQLサーバーのフェイルオーバー戦略が必要です。レプリケーションを実行しましたが、問題なく動作しています。それでも、フェイルオーバー戦略に来るとき、私は一種の無知です...

私は過去数日間インターネットで読んでいます（これは非常に複雑な手順であり、1週間ほどで習得できなかったことを知っています）が、読むほど、混乱が生じます。基本的に、私が理解しているように、ネットワークを監視して障害を報告するソフトウェアと、2つのシステムを切り替えるソフトウェアが必要です。 Heartbeat は、そうするのが明らかに最良ですが、私が読んだすべてのチュートリアルでは、他の多くのソフトウェア（監視用のMONや、ダンプやバックアップを取得するための他のソフトウェアなど）も使用しています。それらが必要ですか？ MySQLとHeartbeatのようなHAツールのみを使用したフェイルオーバー戦略を使用できますか？

各Webサイトは、それぞれ独自の長所と短所を持つさまざまなツールと方法を導入しています。もちろん、それは[〜＃〜] i [〜＃〜]「クラスター」が機能することを望み、システムにとってどの程度の高可用性が重要であるか。私は顧客にそれを指摘することを検討しているだけであり、小規模ビジネスを運営している顧客がそれほどデータを失うことを気にしないので、それはすぐには生産段階には行きませんが、サーバーに障害が発生した場合、クライアントがスタンバイサーバーへの変更を自動的にコミットする単純なマスターマスターレプリケーションをセットアップします。

mysqlreplicationhigh-availability
4
mrz

Master-Master replication modeがあるとおっしゃっていましたが、レプリケーションラグを適切に考慮しない限り、自動フェイルオーバーはお勧めしません。結局のところ、MySQLレプリケーションは非同期です。

理論的には次のことが可能です。

  • DBServer1をマスターとしてDBServer2に
  • DBServer2をマスターとしてDBServer1に
  • DBServer1を指すDBVIP
  • DBServer2は180秒遅れています
  • DBServer1がダウンします
  • 自動フェイルオーバーはDBVIPをDBServer2に移動します

このシナリオでは、DBServer2にまだ存在しない自動インクリメントキーが含まれる可能性があります。フェイルオーバー時に、DBVIPはWebサーバーがDBServer2に接続して、まだ存在しないデータを要求することを許可します。

したがって、これには各DBServerで実行されるバックグラウンドプロセスが必要になります。

上記のシナリオの場合：

  • DBVIPはDBServer1にあります
  • DBServer1はHeartBeatを実行します
  • DBServer2はHeartBeatを実行します
  • 監視するDBServer1のバックグラウンドプロセス
    • a）データマウントの可用性
    • b）データマウントの書き込み可能性
    • c）MySQL接続
    • A、b、またはcが失敗したら、HeartBeatを殺します

DBVIPがping可能であることを確認するためのDBServer2のバックグラウンドプロセス

HeartBeatを倒すとどうなりますか？定義されている起動スクリプトをトリガーします。

DBServer2の起動スクリプトは何を探す必要がありますか？

  • Pingを介してDBVIPに到達できないまでループする
  • MySQLに接続し、
    • SHOW SLAVE STATUS\GがNULLになるまでループでSeconds_Behind_Masterを実行します
    • `Exec_Master_Log_Posが変更を停止するまで、ループ内でRUn SHOW SLAVE STATUS\G
  • DBVIPをDBServer2経由でip addr addに割り当てます

これは、マスター/マスターレプリケーションクラスター内のパッシブマスターに安全にフェイルオーバーするためのアルゴリズムです。

代替

すべてのデータがInnoDBである場合は、厳密性の低いものをお勧めします。おそらく [〜＃〜] drbd [〜＃〜] および HeartBeat の使用を検討する必要があります。理由は次のとおりです。

DRBDは、2つのサーバー上のブロックデバイスにネットワークRAID-1を提供します 。

あなたは本質的にこれを行うでしょう：

  • プライマリとしてDBServer1's DRBDブロックデバイスを使用
  • セカンダリとしてDBServer2's DRBDブロックデバイスを使用
  • / var/lib/mysqlにDBServer1's DRBDデバイスをマウントします
  • MySQLをDBServer1で起動します
  • サーバー間でハートビートモニターのpingアクティビティを実行する

DRBDシナリオでは、起動スクリプトはどのように見えますか？

  • Pingを介してDBVIPに到達できないまでループする
  • ハートハートを倒す
  • DRBDを切断する
  • DRBDをプライマリに昇格
  • DRBDを/ var/lib/mysqlにマウントします
  • MySQLを起動します（InnoDBクラッシュリカバリが不足しているデータを埋めます）
  • ip addr add経由でDBVIPを割り当てます

片側だけがアクティブであるため、これははるかに簡単です。パッシブ側（DRBDセカンダリ）は、アクティブ側（DRBDプライマリ）の同期ディスクコピーです。

警告

すべてまたはほとんどのワーキングセットデータがMyISAMの場合は、DRBDに触れないでください。クラッシュシナリオは、MyISAMテーブルがクラッシュしたとすぐにマークし、自動修復が必要になるまで待機します（これは、待機するのに時間がかかることがあります）。

UPDATE 2012-12-29 08:00 EDT

MySQLでのDRBDの使用に関する過去の投稿です

4
RolandoMySQLDBA