製品をAWSに移行していますが、1.5TBのMySQLデータベースがあります。ダウンタイムを最小限に抑えてAWSに移行したいと思います。以下を実現する予定です。
だから私の質問は、この方法で可能ですか?
私の調査によると、「増分」バックアップのみを復元することはできません。 Perconaが説明したように、完全バックアップを作成してから増分バックアップを作成し、それらを準備して、宛先で復元できる1つの完全バックアップを取得する必要があります。
まず、増分バックアップを作成するには、増分バックアップを作成しているサーバーで完全バックアップを保持する必要があることを理解しましょう。
SERVER(A)で完全バックアップを取りますが、AWSSERVER(B)にプッシュすることができます。それは問題ではありませんが、インクリメンタルを取得するには、完全バックアップコピーをソースバックアップとして保持する必要があります。
[〜#〜] update [〜#〜]
以下はインクリメンタルのアプローチです。あなたが持っているアイデアが実行可能なものであるかどうかにかかわらず、あなたはあなたの答えを得ることができます。
mkdir -p/backup /
innobackupex --defaults-file =/etc/my.cnf --user = mysql --password = ‘****’/backup /
ここから/ backup/2017-06-01_18-01-52完全バックアップセットを取得します。
mkdir -p/backup/INCR
innobackupex --defaults-file =/etc/my.cnf --user = mysql --password = '*****' --incremental/backup/INCR --incremental-basedir =/backup/2017-06-01_18 -01-52 --slave-info
ここから/ backup/INCR/2017-06-01_18-10-41 /インクリメンタルデルタデータが取得されます。
innobackupex --defaults-file =/etc/my.cnf --user = mysql --password = '*****' --apply-log-only/backup/2017-06-01_18-01-52 /- -incremental-dir =/backup/INCR/2017-06-01_18-10-41 /
ここから/ backup/2017-06-01_18-01-52/2017-06-01_18-22-29最終バックアップセットが親(FULL BACKUP)にマージされ、そこからサブディレクトリが作成されます。
innobackupex --defaults-file =/etc/my.cnf --user = mysql --password = '*****' --apply-log/backup/2017-06-01_18-01-52/2017-06 -01_18-22-29
My.cnfが/ mysql/data /を指している場合
- service mysqld stop
- mv/mysql/data/*/tmp/MOVED /
- cp -r/backup/2017-06-01_18-01-52/2017-06-01_18-22-29/*/mysql/data /
- chown -R mysql:mysql/mysql/data /
- chmod -R 775/mysql/data /
- service mysqld start
- Mysqlにログインします
エラーログを確認し、いくつかの選択クエリを実行します。
環境とビジネスが許せば、別の方法で行うこともできます。
バイナリログが有効になっている場合は、マスター情報(バイナリログの位置)を使用して、ソースサーバー(A)からPerconaの完全バックアップを取得します。
ターゲットマシン(AWS)でバックアップを復元します。
ターゲットマシンをソースマシンのスレーブにします(A)。
同期したら、すべてのアプリケーションの呼び出しを数分間停止し、ターゲット(B)を実際のマスターとして作成して読み取りと書き込みの呼び出しを受け入れます。