为什么 Mariabackup 认为我的压缩表已损坏?

为什么 Mariabackup 认为我的压缩表已损坏?

我有一个 MariaDB 数据库(版本 10.2),我正尝试使用 Mariabackup(Percona 的 XtraBackup 的官方分支)进行备份。数据库服务器和备份工具均从 MariaDB Ubuntu 10.2 存储库安装。

由于硬件故障将备份作业移至另一台服务器后,mariabackup现在无法备份特定表。从 stderr 日志中:

[00] 2019-09-10 01:00:01 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /var/run/mysqld/mysqld.sock
[00] 2019-09-10 01:00:01 Using server version 10.2.21-MariaDB-10.2.21+maria~trusty-log
mariabackup based on MariaDB server 10.2.23-MariaDB debian-linux-gnu (x86_64)
[00] 2019-09-10 01:00:01 uses posix_fadvise().
[00] 2019-09-10 01:00:01 cd to /var/lib/mysql/
[00] 2019-09-10 01:00:01 open files limit requested 65535, set to 65535
[00] 2019-09-10 01:00:01 mariabackup: using the following InnoDB configuration:
[00] 2019-09-10 01:00:01 innodb_data_home_dir =
[00] 2019-09-10 01:00:01 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2019-09-10 01:00:01 innodb_log_group_home_dir = ./
[00] 2019-09-10 01:00:01 InnoDB: Using Linux native AIO
[00] 2019-09-10 01:00:01 using O_DIRECT
2019-09-10  1:00:01 140221145274240 [Note] InnoDB: Number of pools: 1
[00] 2019-09-10 01:00:01 mariabackup: Generating a list of tablespaces
…big snip…
2019-09-10  1:42:47 140220995024640 [Note] InnoDB: Read redo log up to LSN=59053785766400
[00] 2019-09-10 01:42:47 >> log scanned up to (59053785785093)
[00] 2019-09-10 01:42:48 >> log scanned up to (59053785831385)
[03] 2019-09-10 01:42:49 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:49 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:49 Database page corruption detected at page 993055, retrying...
[00] 2019-09-10 01:42:49 >> log scanned up to (59053785894073)
[03] 2019-09-10 01:42:49 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Database page corruption detected at page 993055, retrying...
[03] 2019-09-10 01:42:50 Error: failed to read page after 10 retries. File ./database_name/table_name.ibd seems to be corrupted.
2019-09-10  1:42:50 140220969846528 [Note] InnoDB: Page dump in ascii and hex (8192 bytes):
…snipped page dump…
InnoDB: End of page dump
2019-09-10  1:42:50 140220969846528 [Note] InnoDB: Compressed page type (11); stored checksum in field1 1097107227; calculated checksums for field1: crc32 1097107227, innodb 1095451288, none 3735928559; page LSN 57324874439498; page number (if stored to page already) 993055; space id (if stored to page already) 4854
InnoDB: Page may be a compressed BLOB page
[03] 2019-09-10 01:42:50 mariabackup: xtrabackup_copy_datafile() failed.
[00] FATAL ERROR: 2019-09-10 01:42:50 failed to copy datafile.

我已经使用 针对主数据库验证了此副本的完整性pt-table-checksum,没有返回任何错误,因此我认为该表实际上没有损坏。

有问题的表格是压缩的(来自SHOW CREATE TABLE:)ENGINE=InnoDB AUTO_INCREMENT=… DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED。我发现Xtrabackup 的一个未解决的 bug这似乎符合这种情况,但是MariaDB 关于页面压缩的文档似乎说这个问题已在以下版本中得到修复mariabackup

请注意,Percona XtraBackup(自 2.4 版起)不支持 MariaDB 压缩。不过,MariaDB 的分支 MariaDB Backup 可以支持压缩。

这不是数据库中唯一的压缩表,但它似乎是备份工具找到的第一个表。我宁愿不必将这些表重建为未压缩的表。

这看起来像是 Mariabackup 中的一个错误,但我也愿意接受其他建议。

编辑:我已开了一张票:MDEV-20588

相关内容