主页 / dba / 问题 / 159872
Accepted
Stefan Midjich
Asked: 2017-01-04 13:08:16 +0800 CST

恢复 xtrabackup 时“未找到有效检查点”

  • 772

我有一个 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

这对我来说意义不大，所以我在这里寻求帮助。

backup galera

1 个回答

  1. Best Answer

    @jcolebrand 和更多的谷歌搜索帮助我在这个方向上朝着正确的方向前进。

    InnoDB 引擎无法启动。因此，如果我以 myisam 作为默认引擎开始，Show 引擎会显示 InnoDB 不受支持。

    这个 github 问题暗示必须删除一些旧的日志文件。

    具体来说，我删除了以下文件，但 ib_logfile 文件的数量取决于您的系统。

    • aria_log_control
    • ib_logfile0
    • ib_logfile1

    将它们移动到另一个目录并尝试再次启动服务。这对我有用。

    • 1

相关问题