web-dev-qa-db-ja.com

マスター/マスター/スレーブ複製

私が持っているこのDBのレプリケーションをセットアップするための最適なルートに関する情報を取得しようとしています。 MySQL 5.1を使用しています

私は this を見つけました、そしてそれは私たちが考えているアイデアのようです。

メインマスターをマスター/スレーブで複製し、最後のマシンをマスター/スレーブから複製することを検討しています。その解決策は素晴らしいようで、マスター/スレーブマシンで--log-slave-updatesをオンにすると、私が望むように聞こえます。

私の質問は、メインマスター（マスター1）がダウンしたときに、マスター/スレーブ（マスター2）に書き込むようにサービスに指示し、その後マスター1で何が起こるかです。私たちはそれを再構築するなどしていますが、リンクのどこに行きますか？マスター/スレーブ（マスター2）は新しいメインマスターになりますか？また、スレーブのみのマシンはマスター/スレーブに移動されますか？

または、Master1がダウンして再構築され、スレーブマシンをそのまま維持するMaster2（Master/Slave）になりますか？

2つのうち後者のほうだと思います。ただアドバイスを探しています。

ありがとう！

mysqlreplicationmysql-5.1
1
Sezotove

MySQLドキュメント で述べたトポロジを使用する

sxjn

最初のシナリオをセットアップしましょう

各DBサーバーの例IP

  • Master1：10.20.30.40
  • Master2：10.20.30.50
  • Slave_1：10.20.30.60
  • レプリケーションユーザーはrepluser@'%'です
  • レプリケーションパスワードはreplpassです

すべてのスレーブでバイナリログが有効になっていることを確認してください

以下を行います

  • Master2をMaster1に昇格させる
  • Slave_1をMaster2に昇格させる
  • Master1をSlave1に降格

Step 01：Master2で、次を実行します

mysql> SET GLOBAL read_only = 1;
mysql> STOP SLAVE;
mysql> RESET SLAVE;
mysql> CHANGE MASTER TO master_Host='';
mysql> FLUSH TABLES;
mysql> SET GLOBAL read_only = 0;

ステップ02：CNAME/VIPをMaster2に移動します

ステップ03：Slave_1でmysql> RESET MASTER; FLUSH TABLES;を実行します

ステップ04：Slave_1で、データをダンプします

NEW_MASTER_Host="10.20.30.60"
MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
MYSQLDUMP_OPTIONS="--single-transaction"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --routines"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --triggers"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --master-data=1"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --all-databases"
echo "STOP SLAVE;" > MySQLData.sql
echo "CHANGE MASTER TO master_Host='${NEW_MASTER_IP}'," >> MySQLData.sql
echo "master_port=3306," >> MySQLData.sql
echo "master_user='repluser'," >> MySQLData.sql
echo "master_password='replpass'," >> MySQLData.sql
echo "master_log_file='bogus'," >> MySQLData.sql
echo "master_log_pos=1;" >> MySQLData.sql
mysqldump ${MYSQL_CONN} ${MYSQLDUMP_OPTIONS} >> MySQLData.sql
echo "START SLAVE;" >> MySQLData.sql
gzip MySQLData.sql

ステップ05：Master1が再起動すると、rsyncまたはscp MySQLData.sql.gzがSlave_1からMaster1に

ステップ06：Master1でMySQLにログインし、Slave_1から複製するようにセットアップします

実際のバイナリログのファイル名と位置を気にする必要はありません。

--master-data=1を使用すると、標準ダンプの23行目の実際の座標でCHANGE MASTER TOコマンドが埋め込まれます。

以下で見ることができます

less MySQLData.sql.gz | head -35 | tail -1

ステップ07：データをMaster1にロードします

MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
gzip -d < MySQLData.sql.gz | mysql ${MYSQL_CONN}

ステップ08：Master1でMySQLにログインします

mysql> SHOW SLAVE STATUS\G

そしてSlave_IO_RunningとSlave_SQL_Runningの両方がYesと言うことを確認してください

エピローグ

完了したら、トポロジは

  • Master1：10.20.30.50
  • Master2：10.20.30.60
  • Slave_1：10.20.30.40

免責事項

本番環境にデプロイする前に、テストサーバーでこれを試してください。

試してみる ！！！

注：複数のスレーブがあることをお勧めします

  • 毎晩のバックアップ用
  • その他の負荷分散SELECTs
2
RolandoMySQLDBA

プランA：Rolandoが描いたトポロジー：

マスター2がダウンした場合、混乱があります。
マスター1がダウンした場合、リンクを修正するまで有効なスレーブはありません。

プランB：デュアルマスター、シングルライター：

スレーブ<-Master1 <-> Master2-> MoreSlave（s）

[〜＃〜] and [〜＃〜]一度に1つのマスターにのみ書き込みます。これにより、修復手順が最小限になります。

プランC：MHA

マスター->スレーブ

MHAはシステムを監視し、マスターが死亡した場合はスレーブの1つを昇格させます。また、すべてのCHANGE MASTER呼び出しも処理します。

プランD：Galera（Percona XtraDBクラスターまたはMariaDB 10、またはOracleで手動ロール）

あらゆる方法で複製する3つ以上の「ノード」。任意のノードに書き込みます。いずれかのノードがダウンしても、「クラスター」は実行を継続します。ノードを追加すると（クラッシュしたノードを修正するなどして）、すべてのデータのクローンを作成することになっても、クラスターは自動的に修復されます。

さらに、ノードが地理的に3つの場所にある場合は、地震、洪水、竜巻などに対してもHAを使用できます。

私の意見では、DはCより優れており、BはAより優れています。

1
Rick James