web-dev-qa-db-ja.com

MySQLが2番目の増分バックアップを適用すると、ibdataファイルのLSNがib_logfilesのLSNより高くなります

以下で説明するバックアップ手順を使用すると、警告が表示されます。これらの警告は、ベースバックアップに適用されている2番目から6番目（最後）の増分バックアップまで表示されます。

手順でこれを解決するには？

Innobackupexからの警告メッセージ

InnoDB: The log sequence number in the ibdata files is higher than the log sequence number in the ib_logfiles! Are you sure you are using the right ib_logfiles to start up the database. Log sequence number in the ib_logfiles is 12881010402316, logsequence numbers stamped to ibdata file headers are between 12908127655307 and 12908127655307.
InnoDB: The log sequence numbers 12908127655307 and 12908127655307 in ibdata files do not match the log sequence number 12881010402316 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.

そして、これらの多く：

2016-05-31 04:28:16 7f00d9ec5780 InnoDB: Error: page 7 log sequence number 12908127624790
InnoDB: is in the future! Current system log sequence number 12881010402316.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.

それで終わる：

xtrabackup: ########################################################
xtrabackup: # !!WARNING!!                                          #
xtrabackup: # The transaction log file is corrupted.               #
xtrabackup: # The log was not applied to the intended LSN!         #
xtrabackup: ########################################################

バックアップを作成する手順

  • 日曜日に、ベースバックアップを作成します。

innobackupex --stream=xbstream /var/lib/mysql | nc $backup_server $port

  • 月曜日から土曜日、毎日、前のバックアップからの最後のLSNに基づいて増分バックアップを作成します

innobackupex --stream=xbstream --incremental --incremental-lsn=$last_lsn /var/lib/mysql | nc $backup_server $port

バックアップをインポートする手順

日曜日のベースバックアップをスタンバイ環境にインポートします。

  • 基本バックアップをバックアップサーバーから/var/backups/base-<date>にコピーします（そのままにしておきます）
  • MySQLサービスを停止します
  • /var/backups/base-<date>ステージを/var/lib/mysqlにコピー
  • /var/lib/mysqlでバックアップを準備します

Sudo -u mysql innobackupex --ibbackup=/usr/bin/xtrabackup --apply-log /var/lib/mysql

  • MySQLサービスを開始する

月曜日から土曜日までの増分バックアップをスタンバイ環境にインポートします。

  • 増分バックアップをバックアップサーバーから/var/backups/incr-<date>にコピーします
  • 増分を適用するベースバックアップを準備します。

innobackupex --apply-log --defaults-file=/root/.my.cnf --ibbackup=/usr/bin/xtrabackup --redo-only /var/backups/base-<date>

  • 基本バックアップに増分を適用する

innobackupex --apply-log --defaults-file=/root/.my.cnf --ibbackup=/usr/bin/xtrabackup --redo-only /var/backups/base-<date> --incremental-dir=/var/backups/incr-date

  • MySQLサービスを停止します
  • /var/backups/base-<date>ステージを/var/lib/mysqlにコピー
  • /var/lib/mysqlでバックアップを準備します（ステージディレクトリではありません！）

Sudo -u mysql innobackupex --ibbackup=/usr/bin/xtrabackup --apply-log /var/lib/mysql

  • MySQLサービスを開始する
mysqlinnodbrestorebackupxtrabackup
3
Ryo Seph

そのようなメッセージを見ると、通常はREDOログのせいです。これはLSNが書かれている場所です。

この問題は、増分バックアップを準備していないことが原因である可能性があります。

不足しているように見えるのは、 -準備オプション の使用です。

これが本質的に行うことは、特定の時点にロールフォワードされたバックアップを作成することです。これは、バックアップ中にトランザクションが発生した場合に特に当てはまります。

mysqldump --single-transaction の反対のようなもので、バックアップの開始時間に基づいて論理ダンプを作成します。 -xtrabackup で準備すると、バックアップの終了時刻に合わせてREDOログがロールフォワードされます。

Preparing the backup from the XtraBackup Docs の冒頭の段落の内容に注意してください：

--backupを使用してバックアップを作成したら、次のステップはそれを準備することです。データファイルは、準備が整うまでは特定の時点で整合性が取れていません。これは、データファイルがプログラムの実行時にさまざまなタイミングでコピーされ、その間に変更された可能性があるためです。これらのデータファイルを使用してInnoDBを起動しようとすると、破損が検出されてそれ自体がクラッシュし、破損したデータで実行されなくなります。 --prepareステップは、ファイルを一度に完全に一貫させるので、それらに対してInnoDBを実行できます。

これは、インクリメンタルを作成した後、インクリメンタルのLSNを結合する必要があります。

詳細については、 XtraBackupドキュメントからのバックアップの準備 をご覧ください。

3
RolandoMySQLDBA