恢復 xtrabackup 時“未找到有效檢查點”

我有一個 MariaDB 10.1 伺服器集群，主/主，一個節點充當仲裁者，增量備份使用 xtrabackup。

這就是我從文件中拼湊起來的方式。

Master01 使用以下命令進行一次基本備份：

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中。

如果一切看起來都不錯，我會執行另一個腳本來合併增量備份，要點在這裡。

這會導致一個基本備份在大小上看起來與主伺服器上的 Live Copy 相同。

然後我想測試它，所以我innobackupex --copy-back /var/backups/xtrabackup將基本備份複製到 /var/db/mysql 中，這是 /etc/mysql 中配置的數據目錄。

該伺服器沒有安裝 mysqld 二進製文件，因此我將整個目錄同步到與主伺服器具有相同 MariaDB 10.1 版本的還原伺服器。

然後我嘗試使用以下命令以 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

這對我來說意義不大，所以我在這裡尋求幫助。

@jcolebrand 和更多的Google搜尋幫助我在這個方向上朝著正確的方向前進。

InnoDB 引擎無法啟動。因此，如果我以 myisam 作為預設引擎開始，Show 引擎會顯示 InnoDB 不受支持。

這個 github 問題暗示必須刪除一些舊的日誌文件。

具體來說，我刪除了以下文件，但 ib_logfile 文件的數量取決於您的系統。

• aria_log_control
• ib_logfile0
• ib_logfile1

將它們移動到另一個目錄並嘗試再次啟動服務。這對我有用。

引用自：https://dba.stackexchange.com/questions/159872