私は300 GBのmysqlデータベースを持っています。これを別のサーバーに移行して、マスターとマスター間のレプリケーションをセットアップし、最小限のダウンタイムでこれを達成することを主な目的としています。
私のデータベースには、挿入が24時間発生している約30GBのテーブルが1つだけあります。他のすべてのテーブルは履歴テーブル(静的)です。
1)この場合、次に進むための最良の方法は何ですか?
データベース全体のmysqldumpを取得してダンプを他のサーバーに転送し、それを新しいサーバーにインポートすると、私が達成したい仕事を実行できますが、許容できない多くのダウンタイム(おそらく14時間以上)がかかります。
または、mysqlを停止せずに静的テーブルの個々のテーブルダンプを取り、それを新しいサーバーにインポートして、これがすべて終わったら、単一のアクティブテーブルのダウンタイムを取り、新しい挿入が行われず、両方のデータベースが同期するようにすることができます?まず、そんなことは可能でしょうか?可能であれば、マスターマスターレプリケーションのセットアップ中に発生する可能性のある問題は何ですか。
このソリューションはmysqldumpで実行できますが、少しリスクがあります
この例のために、次のものがあるとします。
mydb
です10.20.30.40
です10.20.30.50
ですroot
ですwhatever
ですmysql-bin
ですここにあなたのステップがあります
ライブマスターで、以下を実行します
CREATE USER repluser@'%' IDENTIFIED BY 'replpass';
GRANT REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO repluser@'%';
ターゲットDBサーバーで、以下を実行します。
ソースサーバーとターゲットサーバーでGTIDを有効にしている場合は、次のようにします。
CHANGE MASTER TO
master_Host='10.20.30.40',
master_port=3306,
master_user='repluser',
master_password='replpass',
master_auto_position=1;
ソースサーバーとターゲットサーバーでGTIDを有効にしていない場合は、次のようにします。
CHANGE MASTER TO
master_Host='10.20.30.40',
master_port=3306,
master_user='repluser',
master_password='replpass',
master_log_file='mysql-bin.000001',
master_log_pos=4;
live_dump_and_load.sh
というシェルスクリプトを作成します
その中に次の行を入れてください
MYSQL_USER=root
MYSQL_PASS=whatever
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
DB_TO_DUMP=mydb
MYSQLDUMP_OPTIONS="--routines --triggers"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --master-data=1"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} --single_transaction"
MYSQLDUMP_OPTIONS="${MYSQLDUMP_OPTIONS} -B ${DB_TO_DUMP}"
date > live_dump_and_load.runlog
mysqldump ${MYSQL_CONN} ${MYSQLDUMP_OPTIONS} | mysql -h10.20.30.50 ${MYSQL_CONN}
date >> live_dump_and_load.runlog
chmod +x live_dump_and_load.sh
Nohup ./live_dump_and_load.sh &
watch cat live_dump_and_load.runlog
ダンプがターゲットサーバーにロードされたら、ターゲットサーバーに移動して実行します。
START SLAVE;
xtrabackup
私は以前に同じような状況にあったことがあり、これは本当にこれをとても簡単にします。ダウンタイムを最小限に抑えるためにそれをどのように利用するかについては、あなた次第ですが、考えられるシナリオの1つは次のとおりです。
挿入を停止せずに、新しいサーバーの新しい30GBテーブルを元のサーバーの対応するテーブルと比較して、IDオフセットまたは類似のものに従って更新するだけで、ダウンタイムを解消できます。これは厄介ですが、理由の範囲内で私はダウンタイムを好むでしょう。
編集:xtrabackup_binlog_infoファイルにリストされているログファイルの位置を使用して、ダウンタイムを完全になくすこともできます。
次のリンクを参照してください: https://www.percona.com/doc/percona-xtrabackup/LATEST/howtos/setting_up_replication.html
1週間ほど前に似たようなことをしましたが、MarCPlusPlusに同意します。xtrabackupを使用する方法です。
しかし、私は彼の手順にいくつかの微調整をしています。
-バックアップが完了すると(または直前に)、元のマスターへのすべての書き込みが停止します。
これは、元のデータベースで発生する1秒あたりのトランザクション数によって異なります。私の場合、GTIDのあるinnodbデータベースを使用しており、260GBテーブルに約5kトランザクション/秒を持っています。バックアップの最後のロックは約30秒でした。すべてのクライアントは、私のCPUにある3つのスペアコアを使用して非常に高速に回復しました。顧客は何も気づきませんでした。
あるホストから別のホストにデータをコピーすることは重要です。それには時間がかかり、新しいマシンを起動した後、新しいマシンがマスターに追いつくまでに長い時間がかかります。
追いつくのをスピードアップするには、slave_parallel_workers
を使用します。
置く
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4
新しいホストのMySQL構成ファイル
私の場合、複製は半日でマスターより10時間遅れて追いつきました。