web-dev-qa-db-ja.com

マスタースレーブMysqlレプリケーションの自動フェイルオーバー戦略-なぜこれが機能しないのですか？

クラスター用に指定しているいくつかのMySQLサーバーに対するこのフェイルオーバー戦略についてのフィードバックが欲しいのですが、ここで見逃していない明らかなものがあるかどうかを確認したいと思います。

日常の操作でmysqlマスターサーバーに接続し、マスタースレーブレプリケーションの目的でmysqlサーバーがスレーブとしてセットアップされている1つのアプリサーバー。

Mysqlサーバーに障害が発生した場合、Webアプリでマスターへの接続を試行し、nの試行に失敗した後、次の手順を実行します。

  • マスターが利用できなくなると想定します
  • レプリケーションを停止するためにスレーブサーバーにシグナルを送信します
  • スレーブサーバーにシグナルを送信して、新しいmysqlマスターとして機能するように指示します
  • サーバーへの接続を再開し、これからはマスターのように扱います

アプリが再び起動し、ユーザーにサービスを提供したら、バックグラウンドで新しいスレーブサーバーを起動できるようにしたいと思います。リクエストを処理する準備ができたら、マスタースレーブレプリケーションをもう一度セットアップして、同じフェイルオーバーサポートを提供します。前。

これは以前に行われたことは確かですが、これに関するガイドは見当たらないので、私がまだ考えていない、これを試さない明らかな理由があるに違いないと思います。

MySQLでこのような自動フェイルオーバーを提供するためにこのアプローチを採用することの落とし穴は何ですか？

余談ですが、マスターとマスターのレプリケーションについては知っていますが、a）ひどくうまくいかないのを見て、b）心配そうに複雑になっているようです。

ありがとう

mysqlreplicationmaster-slave
4
Chris Adams

自動フェイルオーバーが役に立たない理由は、レプリケーションの遅延と関係があります。スレーブが遅れてフェイルオーバーが発生した場合は、マスターからの挿入がまだ書き込まれていないため、まだ存在しないキーを使用して更新を書き込んでいる可能性があります。レプリケーションの遅延が大きいほど、これは問題になります。私の会社では、フェイルオーバー先のDRBDサーバーが元のマスターの正確なディスクレベルのコピーであるため、自動フェイルオーバーにDRBDを使用しています。ポリシーとして、マスター/スレーブおよびマスター/マスターセットアップのフェイルオーバーの手動を行います。

2
RolandoMySQLDBA

必要なのは高可用性クラスターであり、提案されたアプローチは少し奇妙に思えると思います。

これを実現する良い方法は、Linux HAクラスターを作成し、ファイルシステムレベルでDRDB同期を使用してMySQLを同期することです。

このような設定では、次の3つがあります。

  1. クラスターメッセージングレイヤー（Linux-HAまたはCoroSync）
  2. クラスターリソースマネージャー（ペースメーカー）
  3. ディスク同期（DRDB）

アプリケーションで多くのコードを作成する代わりに、現在アクティブなノードに移動する仮想IPアドレスを使用します。また、STONITH（Shoot The Other Node In The Head（私はこれを構成しませんでした）））を使用して、リソースを引き継ぐ前に最初のノードが実際に停止していることを確認します。

これらのリンクで読むべきいくつかの素晴らしい資料があります： http://www.linux-ha.org/wiki/Main_Pagehttp://www.clusterlabs.org/wiki/DRBD_MySQL_HowTohttp://theclusterguy.clusterlabs.org/

3
Frands Hansen

マスターマスターレプリケーションを除外するつもりはありません。実際、あなたが説明しているのは、ほとんどマスターマスターレプリケーションです。

MMM（Multi-Master Replication Manager for MySQL）をご覧ください。 http://mysql-mmm.org/ mysqlレイヤーで機能するため、OSベースのクラスタリングよりもはるかに優れています。

0
Mark Wagner