web-dev-qa-db-ja.com

xtrabackupの復元時に「有効なチェックポイントが見つかりません」

MariaDB 10.1サーバーのクラスター、1つのノードがアービトレーターとして機能するマスター/マスター、およびxtrabackupを使用した増分バックアップがあります。

これは、ドキュメントからまとめた方法です。

Master01は、次のコマンドを使用してベースバックアップを1回実行します。

innobackupex --defaults-file="/etc/xtrabackup_client/backup.cnf" \
  --socket="..." --extra-lsndir="/etc/xtrabackup_client/" \
  --stream=xbstream /tmp | \
  ssh "$backup_username@$backup_server"  "cat - | xbstream -x -C /var/backups/xtrabackup/"

その後、次のコマンドで毎日増分バックアップを実行します。

innobackupex --defaults-file="$mysql_defaults_file" \
  --socket="..." --extra-lsndir="/etc/xtrabackup_client" --stream=xbstream \
  --incremental --incremental-lsn="$to_lsn" /tmp | \
  ssh "$backup_username@$backup_server" "cat - | xbstream -x -C /var/backups/xtrabackup_incremental/"

/etc/xtrabackup_client/backup.cnfは次のようになります。

[client]
user=backup
password=secret

これはスクリプトで行われるため、変数はあちこちにあります。 （明確にするために、一部を削除しました。）

これは機能しているようです。ベースバックアップを取得し、増分バックアップを作成します。

復元テストを実行しようとすると、問題が発生します。

復元するには、調停ノードでこの手順に従います

最初に、ベースバックアップとすべての増分バックアップを新しい順にループし、LSNを確認するスクリプトを実行します。

スクリプトを Gist here に貼り付けました。

問題がなければ、別のスクリプトを実行して増分バックアップをマージします Gist here 。

これにより、1つのベースバックアップが作成され、サイズによってマスターサーバーのライブコピーと同じように見えます。

次に、それをテストしたいので、innobackupex --copy-back /var/backups/xtrabackupこれは、/ etc/mysqlで構成されたdatadirである/ var/db/mysqlに基本バックアップをコピーします。

そのサーバーにはmysqldバイナリがインストールされていないため、マスターサーバーと同じMariaDB 10.1バージョンの復元サーバーにディレクトリ全体をrsyncします。

次に、次のコマンドを使用してrootとして実行しようとします。

Sudo -u mysql /usr/sbin/mysqld --basedir=/usr \
  --datadir=/var/db/mysql --plugin-dir=/usr/lib/mysql/plugin \
  --user=mysql --pid-file=/var/run/mysqld/mysqld.pid \
  --socket=/var/run/mysqld/mysqld.sock --port=3306

しかし、私はこの出力を取得します：

2017-01-03 18:55:41 140551642929088 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB-1~trusty) starting as process 24455 ...
2017-01-03 18:55:41 140551642929088 [Note] Using unique option prefix 'myisam_recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: The InnoDB memory heap is disabled
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Using Linux native AIO
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Using SSE crc32 instructions
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Completed initialization of buffer pool
2017-01-03 18:55:41 140551642929088 [Note] InnoDB: Highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
InnoDB: please refer to http://dev.mysql.com/doc/refman/5.6/en/upgrading-downgrading.html
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
2017-01-03 18:55:41 140551642929088 [ERROR] Plugin 'InnoDB' init function returned error.
2017-01-03 18:55:41 140551642929088 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-01-03 18:55:41 140551642929088 [Note] Plugin 'FEEDBACK' is disabled.
2017-01-03 18:55:41 140551642929088 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-01-03 18:55:41 140551642929088 [ERROR] Aborting

それは私にはほとんど意味がないので、私はここで助けを求めています。

galerabackupmariadb-10.1xtrabackup
2
Stefan Midjich

@jcolebrandと他のいくつかのグーグルは、これを正しい方向に導くのに役立ちました。

InnoDBエンジンが起動に失敗しています。そのため、デフォルトのエンジンとしてmyisamを開始した場合、ShowエンジンはInnoDBがサポートされていないことを示しました。

このgithubの問題 は、いくつかの古いログファイルを削除する必要があることを示唆していました。

具体的には、次のファイルを削除しましたが、ib_logfileファイルの数はシステムによって異なります。

  • aria_log_control
  • ib_logfile0
  • ib_logfile1

それらを別のディレクトリに移動して、サービスを再起動してください。これでうまくいきました。

1
Stefan Midjich