Mysqlレプリケーションの場合、マスターとスレーブに異なるデータベースがある場合、Mysql DBを再同期するにはどうすればよいですか？
Mysql Server1はMASTERとして実行されています。
MySQL Server2はSLAVEとして実行されています。
現在、DBレプリケーションはMASTERからSLAVEに行われています。
Server2はネットワークから削除され、1日後に再接続されます。この後、マスターとスレーブのデータベースに不一致があります。
マスターからスレーブに取得したDBを復元しても問題が解決しないので、DBを再同期するにはどうすればよいですか？
これは、マスタースレーブレプリケーションを最初から再同期するための完全なステップバイステップの手順です。
マスターで：
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
そして結果の値をコピー最後のコマンドのどこかに。
クライアントへの接続を閉じずに（読み取りロックを解除するため）、マスターのダンプを取得するコマンドを発行します。
mysqldump -u root -p --all-databases > /a/path/mysqldump.sql
ダンプがまだ終了していなくても、ロックを解除できます。それを行うには、MySQLクライアントで次のコマンドを実行します。
UNLOCK TABLES;
次に、scpまたは任意のツールを使用して、ダンプファイルをスレーブにコピーします。
スレーブで：
Mysqlへの接続を開き、次を入力します。
STOP SLAVE;
次のコンソールコマンドを使用して、マスターのデータダンプをロードします。
mysql -uroot -p < mysqldump.sql
スレーブログとマスターログを同期します。
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;
上記のフィールドの値は、以前にコピーしたものです。
最後に、次を入力します。
START SLAVE;
次のように入力した後、すべてが再び機能することを確認するには：
SHOW SLAVE STATUS;
君は見るべきだ：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
それでおしまい！
MySQLサイトでのこのドキュメントは非常に古く、フットガン（interactive_timeoutなど）でいっぱいです。マスターのエクスポートの一部としてREAD LOCKを使用してFLUSH TABLESを発行することは、通常、LVMやzfsなどのストレージ/ファイルシステムスナップショットと調整する場合にのみ意味があります。
Mysqldumpを使用する場合は、代わりに--master-dataオプションを使用して、人為的なエラーを防ぎ、マスターのロックをできるだけ早く解除する必要があります。
マスターが192.168.100.50、スレーブが192.168.100.51、各サーバーに個別のサーバーIDが構成され、マスターにバイナリログオンがあり、スレーブにmy.cnfの読み取り専用= 1があると仮定します
ダンプをインポートした直後にレプリケーションを開始できるようにスレーブをステージングするには、CHANGE MASTERコマンドを発行しますが、ログファイルの名前と位置は省略します。
slaveserver> CHANGE MASTER TO MASTER_Host='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';
使用するスレーブのマスターでGRANTを発行します。
masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';
圧縮を使用してマスターを（画面で）エクスポートし、正しいバイナリログ座標を自動的にキャプチャします。
mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz
Replication.sql.gzファイルをスレーブにコピーし、それをzcatでスレーブで実行されているMySQLのインスタンスにインポートします。
zcat replication.sql.gz | mysql
スレーブにコマンドを発行してレプリケーションを開始します。
slaveserver> START SLAVE;
必要に応じて、スレーブの/root/.my.cnfを更新して、マスターと同じルートパスワードを保存します。
5.1以降を使用している場合は、まずマスターのbinlog_formatをMIXEDまたはROWに設定することをお勧めします。主キーがないテーブルでは、行に記録されるイベントが遅いことに注意してください。通常、これは、スレーブ上で間違ったデータを生成する可能性が低いため、binlog_format = statement（マスター上）の代替（およびデフォルト）構成よりも優れています。
レプリケーションをフィルターする必要がある場合は（そうすべきではありません）、スレーブオプションreplicate-wild-do-table = dbname。％またはreplicate-wild-ignore-table = badDB。％でフィルターし、binlog_format = rowのみを使用します。
このプロセスは、mysqldumpコマンドが実行されている間、マスターのグローバルロックを保持しますが、マスターに影響を与えることはありません。
Mysqldump --master-data --all-databases --single-transaction（InnoDBテーブルのみを使用しているため）を使用したい場合は、MySQL Enterprise Backupまたはxtrabackupと呼ばれるオープンソース実装を使用することをお勧めします（提供：パーコナ）
スレーブ（Server2）に直接書き込む場合を除き、唯一の問題は、Server2が切断されてから発生した更新が欠落していることです。 「START SLAVE;」でスレーブを再起動するだけです。すべてを高速に戻す必要があります。
Maatkit utilitsが役立つと思います！ mk-table-syncを使用できます。このリンクを参照してください： http://www.maatkit.org/doc/mk-table-sync.html
私はこの質問に非常に遅れていますが、この問題に遭遇し、多くの検索をした後、Bryan Kennedyからこの情報を見つけました： http://plusbryan.com/mysql-replication-without-downtime
マスターで次のようなバックアップを作成します。
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A>〜/ dump .sql
次に、ファイルの先頭を調べて、MASTER_LOG_FILEおよびMASTER_LOG_POSの値を書き留めます。後で必要になります：head dump.sql -n80 | grep "MASTER_LOG"
「dump.sql」ファイルをスレーブにコピーして復元します：mysql -u mysql-user -p <〜/ dump.sql
スレーブmysqlに接続し、次のようなコマンドを実行します：CHANGE MASTER TO MASTER_Host = 'master-server-ip'、MASTER_USER = 'replication-user'、MASTER_PASSWORD = 'slave-server-password' 、MASTER_LOG_FILE =「上からの値」、MASTER_LOG_POS =上からの値。スレーブ開始;
スレーブの進行状況を確認するには：SHOW SLAVE STATUS;
すべてが正常であれば、Last_Errorは空白になり、Slave_IO_Stateは「マスターがイベントを送信するのを待機しています」と報告します。 Seconds_Behind_Masterを探して、その遅れを示します。 YMMV。 :)
デビッドの答えをフォローアップしています...
SHOW SLAVE STATUS\Gを使用すると、人間が読み取れる出力が得られます。
Mysqlスレーブが同期しなくなったときに私が通常行うことは次のとおりです。私はmk-table-syncを見てきましたが、リスクセクションは恐ろしいと思いました。
マスターについて：
SHOW MASTER STATUS
出力された列（ファイル、位置）は少し役立ちます。
スレーブ上：
STOP SLAVE
次に、マスターデータベースをダンプし、スレーブデータベースにインポートします。
次に、次を実行します。
CHANGE MASTER TO
MASTER_LOG_FILE='[File]',
MASTER_LOG_POS=[Position];
START SLAVE;
[File]と[Position]は、上記で実行した「SHOW MASTER STATUS」から出力された値です。
お役に立てれば！
時にはあなたも奴隷にキックを与える必要がある
試してみる
stop slave;
reset slave;
start slave;
show slave status;
かなり頻繁に、奴隷、彼らはただ立ち往生します:)
うまくいけば他の人を助ける完全な答えがあります...
マスターとスレーブを使用してmysqlレプリケーションをセットアップしたいのですが、ログファイルを使用して同期することしかわかっていなかったため、スレーブがオフラインになって同期が取れなくなった場合、理論的には接続し直すだけで済みますユーザーmalonsoが述べたように、そのマスターに、中断したところからログファイルを読み続けます。
次のように、マスターとスレーブを構成した後のテスト結果は次のとおりです。 http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...
推奨されるマスター/スレーブ構成を使用し、スレーブへの書き込みを行わない場合、彼と私は適切です（mysql-server 5.xに関する限り）。 「START SLAVE;」を使用する必要さえありませんでした。マスターに追いついただけです。しかし、デフォルトの88000が60秒ごとに再試行するため、スレーブを開始または再起動しなければならない可能性があると推測します。とにかく、スレーブがオフラインになり、再びバックアップする必要があるかどうかを知りたい私のような人にとっては、手動の介入が必要です。いいえ、そうではありません。
元のポスターのログファイルが破損している可能性がありますか？しかし、おそらく、サーバーが1日オフラインになるだけではありません。
/usr/share/doc/mysql-server-5.1/README.Debian.gzから取得します。これは、Debian以外のサーバーでもおそらく意味があります。
*複製に関する追加の注意事項 =============================== MySQLサーバーの場合レプリケーションスレーブとして機能している場合、メモリベースのファイルシステム上のディレクトリまたはサーバーホストの再起動時にクリアされるディレクトリを指す set --tmpdirを設定しないでください。レプリケーション スレーブは、マシンの再起動に耐えるために一時ファイルのいくつかを必要とするため、 一時テーブルまたはLOAD DATA INFILE操作を複製できます。サーバーの再起動時に一時ファイルディレクトリ内の ファイルが失われた場合、 レプリケーションは失敗します。
次のようなsqlを使用できます： 'tmpdir'などの変数を表示します;を見つけます。
このエラーを含める一般的な回答に追加：
"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",
ワンショットでのスレーブからの複製：
1つのターミナルウィンドウで：
mysql -h <Master_IP_Address> -uroot -p
接続した後、
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
ステータスは次のように表示されます。ポジション番号は異なることに注意してください！
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | your_DB | |
+------------------+----------+--------------+------------------+
彼が「別の端末を使用！」と説明したのと同様にダンプをエクスポートします。
終了して、独自のDB（スレーブ）に接続します。
mysql -u root -p
以下のコマンドを入力します。
STOP SLAVE;
前述のように（もちろん、別のターミナルで）ダンプをインポートし、以下のコマンドを入力します。
RESET SLAVE;
CHANGE MASTER TO
MASTER_Host = 'Master_IP_Address',
MASTER_USER = 'your_Master_user', // usually the "root" user
MASTER_PASSWORD = 'Your_MasterDB_Password',
MASTER_PORT = 3306,
MASTER_LOG_FILE = 'mysql-bin.000001',
MASTER_LOG_POS = 98; // In this case
ログに記録したら、server_idパラメーターを設定します（通常、新規/複製されないDBの場合、これはデフォルトでは設定されません）。
set global server_id=4000;
次に、スレーブを起動します。
START SLAVE;
SHOW SLAVE STATUS\G;
出力は、彼が説明したものと同じでなければなりません。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
注：複製されると、マスターとスレーブは同じパスワードを共有します！
LVMを使用してスレーブを再構築する
Linux LVMを使用してMySQLスレーブを再構築するために使用する方法を次に示します。これにより、マスターでのダウンタイムを最小限に抑えながら、一貫したスナップショットが保証されます。
マスターMySQLサーバーでinnodb max dirty pages percentをゼロに設定します。これにより、MySQLはすべてのページをディスクに強制的に書き込み、再起動を大幅に高速化します。
set global innodb_max_dirty_pages_pct = 0;
ダーティページの数を監視するには、コマンドを実行します
mysqladmin ext -i10 | grep dirty
数が減少しなくなると、続行するポイントに到達します。次に、マスターをリセットして、古いbinログ/リレーログをクリアします。
RESET MASTER;
Lvdisplayを実行してLVパスを取得します
lvdisplay
出力は次のようになります
--- Logical volume ---
LV Path /dev/vg_mysql/lv_data
LV Name lv_data
VG Name vg_mysql
コマンドでmasterデータベースをシャットダウンします
service mysql stop
次にスナップショットを取得すると、mysql_snapshotが新しい論理ボリューム名になります。 binlogがOSドライブに配置されている場合、それらもスナップショットである必要があります。
lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data
コマンドでマスターを再起動します
service mysql start
ダーティページ設定をデフォルトに戻す
set global innodb_max_dirty_pages_pct = 75;
再度lvdisplayを実行して、スナップショットがそこに表示されていることを確認します
lvdisplay
出力：
--- Logical volume ---
LV Path /dev/vg_mysql/mysql_snapshot
LV Name mysql_snapshot
VG Name vg_mysql
スナップショットをマウントする
mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot
既存のMySQLスレーブを実行している場合は、停止する必要があります
service mysql stop
次に、MySQLデータフォルダーをクリアする必要があります
cd /var/lib/mysql
rm -fr *
マスターに戻ります。次に、スナップショットをMySQLスレーブにrsyncします
rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/
Rsyncが完了したら、スナップショットをアンマウントして削除できます。
umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot
古いレプリケーションユーザーが存在しないか、パスワードが不明な場合、マスターにレプリケーションユーザーを作成します
GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';
/ var/lib/mysqlデータファイルがmysqlユーザーによって所有されていることを確認します。所有している場合は、次のコマンドを省略できます。
chown -R mysql:mysql /var/lib/mysql
次に、binlogの位置を記録します
ls -laF | grep mysql-bin
次のようなものが表示されます
..
-rw-rw---- 1 mysql mysql 1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw---- 1 mysql mysql 1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw---- 1 mysql mysql 963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw---- 1 mysql mysql 65657162 Aug 28 16:44 mysql-bin.000020
ここで、マスターログファイルは順番に最大のファイル番号であり、ビンログの位置はファイルサイズです。これらの値を記録します。
master_log_file=mysql-bin.000020
master_log_post=65657162
次にスレーブMySQLを起動します
service mysql start
以下を実行して、スレーブでマスター変更コマンドを実行します。
CHANGE MASTER TO
master_Host="10.0.0.12",
master_user="replication",
master_password="YourPass",
master_log_file="mysql-bin.000020",
master_log_pos=65657162;
最後にスレーブを開始します
SLAVE START;
スレーブステータスを確認します。
SHOW SLAVE STATUS;
スレーブIOが実行されており、接続エラーがないことを確認してください。がんばろう！
BR、ジュハ・ベニア
私は最近ここにある私のブログにこれを書きました...そこにはさらにいくつかの詳細がありますが、話は同じです。
http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html
MySQLのマスター/マスターレプリケーション手法を使用しており、1つのMySQLサーバーがネットワークから1が削除された場合、接続が復元され、ネットワークにあったサーバー2でコミットされたすべてのレコードが転送された後に再接続します復元後に接続を失ったサーバー1へ。 MySQLのスレーブスレッドは、デフォルトで60秒ごとにマスターへの接続を再試行します。このプロパティは、MySQLが「master_connect_retry = 5」というフラグを持っているため、5秒で変更できます。これは、5秒ごとに再試行することを意味します。
ただし、重複したキーエラーエラーコード：1062が表示されるため、接続を失ったサーバーがデータベースにコミットしないことを確認する必要があります。
この問題を迅速に解決するスクリプトを使用してGitHubリポジトリを作成しました。いくつかの変数を変更して実行するだけです（最初に、スクリプトがデータベースのバックアップを作成します）。
これがあなた（そして他の人たち）にも役立つことを願っています。