153

MysqlはMASTERServer1として実行されています。 MysqlはSLAVEとして実行されています。
Server2

これでMASTERからSLAVEへの DB レプリケーションが行われます。

Server2をネットワークから削除し、1 日後に再接続します。この後、マスターとスレーブのデータベースに不一致があります。

マスターからスレーブに取得した DB を復元した後も問題が解決しないため、DB を再同期する方法は?

4

14 に答える 14

309

これは、マスター/スレーブ レプリケーションを最初から再同期するための段階的な完全な手順です。

マスターで:

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

それでおしまい！

于 2010-07-12T15:08:00.400 に答える
34

これに関する MySQL サイトのドキュメントはひどく時代遅れであり、フットガン (interactive_timeout など) でいっぱいです。マスターのエクスポートの一部として FLUSH TABLES WITH READ LOCK を発行することは、通常、LVM や zfs などのストレージ/ファイルシステムのスナップショットと連携している場合にのみ意味があります。

mysqldump を使用する場合は、代わりに --master-data オプションを使用して人的エラーを防ぎ、マスターのロックをできるだけ早く解放する必要があります。

マスターが 192.168.100.50 でスレーブが 192.168.100.51 であると仮定します。各サーバーには個別のサーバー ID が構成されており、マスターにはバイナリ ログオンがあり、スレーブには my.cnf で read-only=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 の代替 (およびデフォルト) 構成よりも優れています。

レプリケーションをフィルタリングする必要がある場合 (おそらくそうすべきではない) は、スレーブ オプションの replica-wild-do-table=dbname.% または replica-wild-ignore-table=badDB.% を使用して行い、binlog_format=row のみを使用します。

このプロセスは、mysqldump コマンドが実行されている間、マスターでグローバル ロックを保持しますが、マスターに影響を与えることはありません。

mysqldump --master-data --all-databases --single-transaction を使用したくなる場合 (InnoDB テーブルのみを使用するため)、MySQL Enterprise Backup または xtrabackup と呼ばれるオープン ソース実装を使用することをお勧めします (提供:ペルコナ)

于 2013-10-29T17:22:06.157 に答える
18

スレーブ (Server2) に直接書き込みを行っていない限り、唯一の問題は、Server2 が切断されてから発生した更新がないことです。「START SLAVE;」でスレーブを再起動するだけです。すべてを元の速度に戻す必要があります。

于 2010-03-08T22:14:48.193 に答える
8

Maatkit utilits が役立つと思います。mk-table-sync を使用できます。このリンクを参照してください: http://www.maatkit.org/doc/mk-table-sync.html

于 2010-03-02T19:45:53.390 に答える
6

これは、mysqlスレーブが同期しなくなったときに私が通常行うことです。私はmk-table-syncを見てきましたが、リスクのセクションは怖いものだと思いました。

マスターについて：

SHOW MASTER STATUS

出力された列（ファイル、位置）は少し役に立ちます。

スレーブ上：

STOP SLAVE

次に、マスターデータベースをダンプし、スレーブデータベースにインポートします。

次に、以下を実行します。

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

ここで、[File]と[Position]は、上記の「SHOWMASTERSTATUS」から出力された値です。

お役に立てれば！

于 2010-03-19T17:30:35.117 に答える
2

これは、うまくいけば他の人を助ける完全な答えです...

マスターとスレーブを使用して 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 サーバーがレプリケーション スレーブとして機能している場合、
--tmpdir を設定して、メモリベースのファイルシステム上のディレクトリを指すか、
サーバー ホストの再起動時にクリアされるディレクトリ。複製
スレーブは、マシンの再起動に耐えるために一時ファイルの一部を必要とするため、
一時テーブルまたは LOAD DATA INFILE 操作をレプリケートできること。もしも
サーバーの再起動時に、一時ファイル ディレクトリ内のファイルが失われます。
複製は失敗します。

次のようなSQLを使用できます。「tmpdir」などの変数を表示します。調べるために。

于 2011-10-05T02:07:47.803 に答える
2

このエラーを含めるために、一般的な回答に追加します。

"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

注: レプリケートされると、マスターとスレーブは同じパスワードを共有します。

于 2013-05-22T04:44:44.627 に答える
1

LVM を使用してスレーブを再構築する

Linux LVM を使用して MySQL スレーブを再構築するために使用する方法を次に示します。これにより、マスターのダウンタイムを最小限に抑えながら、一貫したスナップショットが保証されます。

マスター MySQL サーバーで innodb ダーティ ページの最大パーセントをゼロに設定します。これにより、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

次にバイナリログの位置を記録します

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 が実行中で、接続エラーがないことを確認してください。幸運を！

私は最近、ここにある私のブログにこれを書きました...詳細はほとんどありませんが、話は同じです.

http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html

于 2015-05-21T20:06:27.573 に答える
1

時々、奴隷にもキックを与える必要があるだけです

試す

stop slave;    
reset slave;    
start slave;    
show slave status;

多くの場合、奴隷、彼らは立ち往生するだけです:)

于 2014-10-15T16:07:24.707 に答える
0

この問題を迅速に解決するためのスクリプトを含む GitHub リポジトリを作成しました。いくつかの変数を変更して実行するだけです (最初に、スクリプトはデータベースのバックアップを作成します)。

これがあなた（そして他の人も）に役立つことを願っています。

MySQL マスター/スレーブ レプリケーションをリセット (再同期) する方法

于 2015-03-02T18:12:43.890 に答える
0

MySQL のマスター - マスター複製技術を使用しており、1 つの MySQL サーバーがネットワークから削除されたと言うと、接続が復元された後に再接続し、ネットワーク内にあったサーバー 2 でコミットされたすべてのレコードが転送されます。復旧後に接続を失ったサーバー 1 に送信します。デフォルトでは、MySQL のスレーブ スレッドは 60 秒ごとにマスターへの接続を再試行します。このプロパティは、MySQL が "master_connect_retry=5" というフラグを持っているため変更できます。ここで、5 は秒です。これは、5 秒ごとに再試行することを意味します。

ただし、接続を失ったサーバーがデータベースにコミットしていないことを確認する必要があります。重複したキーエラーエラーコード: 1062

于 2018-09-15T07:46:13.480 に答える