web-dev-qa-db-ja.com

300 GBのmysqlデータベースを1つのサーバーから別のサーバーに最小限のダウンタイムでクリーンに移行

私は300 GBのmysqlデータベースを持っています。これを別のサーバーに移行して、マスターとマスター間のレプリケーションをセットアップし、最小限のダウンタイムでこれを達成することを主な目的としています。

私のデータベースには、挿入が24時間発生している約30GBのテーブルが1つだけあります。他のすべてのテーブルは履歴テーブル（静的）です。

1）この場合、次に進むための最良の方法は何ですか？

  • データベース全体のmysqldumpを取得してダンプを他のサーバーに転送し、それを新しいサーバーにインポートすると、私が達成したい仕事を実行できますが、許容できない多くのダウンタイム（おそらく14時間以上）がかかります。

  • または、mysqlを停止せずに静的テーブルの個々のテーブルダンプを取り、それを新しいサーバーにインポートして、これがすべて終わったら、単一のアクティブテーブルのダウンタイムを取り、新しい挿入が行われず、両方のデータベースが同期するようにすることができます？まず、そんなことは可能でしょうか？可能であれば、マスターマスターレプリケーションのセットアップ中に発生する可能性のある問題は何ですか。

  • または、ダウンタイムを非常に少なくしてこれを行う他の方法はありますか？
mysqlreplicationrestoremysqldumpmaster-master-replication
4
AJAY

このソリューションはmysqldumpで実行できますが、少しリスクがあります

この例のために、次のものがあるとします。

  • データベース名はmydbです
  • ソースDBサーバーのプライベートIPは10.20.30.40です
  • ターゲットDBサーバーのプライベートIPは10.20.30.50です
  • ユーザーは、ソースDBサーバーとターゲットDBサーバーの両方でrootです
  • ソースとターゲットの両方のDBサーバーでのパスワードはwhateverです
  • 両方のサーバーのバイナリログの名前はmysql-binです

ここにあなたのステップがあります

ステップ01：レプリケーションユーザーの作成

ライブマスターで、以下を実行します

CREATE USER repluser@'%' IDENTIFIED BY 'replpass';
GRANT REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO repluser@'%';

ステップ02：レプリケーションを設定する

ターゲット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;

ステップ03：ライブmysqldumpを実行してロードするスクリプトを作成する

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

ステップ04：シェルスクリプトを実行する

chmod +x live_dump_and_load.sh
Nohup ./live_dump_and_load.sh &

ステップ05：実行ログを監視する

watch cat live_dump_and_load.runlog

ステップ06：レプリケーションを開始する

ダンプがターゲットサーバーにロードされたら、ターゲットサーバーに移動して実行します。

START SLAVE;

試してみる ！！！

5
RolandoMySQLDBA

xtrabackup

私は以前に同じような状況にあったことがあり、これは本当にこれをとても簡単にします。ダウンタイムを最小限に抑えるためにそれをどのように利用するかについては、あなた次第ですが、考えられるシナリオの1つは次のとおりです。

  • ホットバックアップ機能を使用して、実際のバックアップ作成中のダウンタイムを排除します。
  • バックアップが終了したら（または直前に）、元のマスターへのすべての書き込みを停止します。
  • rsyncまたはlftpまたはそのようなもの（bittorentは絶対的に高速ですが、おそらく新しいスレーブが地理的に元のスレーブから遠い場合にのみ必要です）。
  • 新しいスレーブをできるだけ早く起動します。すべての構成、セットアップなどがすでに整っているはずです。
  • レプリケーションをアクティブにして、元のマスターで書き込みを再度有効にします。

挿入を停止せずに、新しいサーバーの新しい30GBテーブルを元のサーバーの対応するテーブルと比較して、IDオフセットまたは類似のものに従って更新するだけで、ダウンタイムを解消できます。これは厄介ですが、理由の範囲内で私はダウンタイムを好むでしょう。

編集：xtrabackup_binlog_infoファイルにリストされているログファイルの位置を使用して、ダウンタイムを完全になくすこともできます。

次のリンクを参照してください： https://www.percona.com/doc/percona-xtrabackup/LATEST/howtos/setting_up_replication.html

0
MarCPlusPlus

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時間遅れて追いつきました。

0
jgnoss