MariaDB备份工具Mariabackup失败并出现错误

时间:2018-05-01 11:22:14

标签: mysql database backup mariadb innobackupex

我们最近从MariaDB 5.5升级到10.2,并从innobackupex换成了Mariadbackup(xtrabackup的一个分支)。尝试进行完整备份总是失败。

我用:

运行备份

sudo mariabackup --backup --target-dir /mnt/database_backups/test --user backups --password REDACTED

命令的输出如下:

180501 11:53:30 Connecting to MySQL server host: localhost, user: backups, password: set, port: 3306, socket: /var/run/mysqld/mysqld.sock
Using server version 10.2.14-MariaDB-10.2.14+maria~trusty-log
mariabackup based on MariaDB server 10.2.14-MariaDB debian-linux-gnu (x86_64)
mariabackup: uses posix_fadvise().
mariabackup: cd to /var/lib/mysql/
mariabackup: open files limit requested 0, set to 1024
mariabackup: using the following InnoDB configuration:
mariabackup:   innodb_data_home_dir = .
mariabackup:   innodb_data_file_path = ibdata1:12M:autoextend
mariabackup:   innodb_log_group_home_dir = ./
mariabackup: using O_DIRECT
2018-05-01 11:53:30 140057835345792 [Note] InnoDB: Number of pools: 1
mariabackup: Generating a list of tablespaces
2018-05-01 11:53:30 140057835345792 [Warning] InnoDB: Allocated tablespace ID 2997 for warehouse/warehouses, old maximum was 0
180501 11:53:34 >> log scanned up to (2154583932391)
180501 11:53:34 [01] Copying ./ibdata1 to /mnt/database_backups/test/ibdata1
180501 11:53:35 >> log scanned up to (2154583953963)
180501 11:53:35 [01]        ...done
180501 11:53:35 [01] Copying ./warehouse/warehouses.ibd to /mnt/database_backups/test/warehouse/warehouses.ibd
180501 11:53:35 [01]        ...done

-- MORE Copying... ...done lines

180501 12:09:59 [01] Copying ./vioadmin/amazon__product_blacklist.ibd to /mnt/database_backups/test/vioadmin/amazon__product_blacklist.ibd
180501 12:09:59 [01]        ...done
180501 12:09:59 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180501 12:09:59 Executing FLUSH TABLES WITH READ LOCK...
180501 12:09:59 Starting to backup non-InnoDB tables and files
180501 12:09:59 [01] Copying ./warehouse/warehouse_actions_archive.frm to /mnt/database_backups/test/warehouse/warehouse_actions_archive.frm
180501 12:09:59 [01]        ...done

-- MORE Copying... ...done lines

180501 12:10:01 Finished backing up non-InnoDB tables and files
180501 12:10:01 [01] Copying aria_log_control to /mnt/database_backups/test/aria_log_control
180501 12:10:01 [01]        ...done
180501 12:10:01 [01] Copying aria_log.00000001 to /mnt/database_backups/test/aria_log.00000001
180501 12:10:01 [01]        ...done
180501 12:10:01 [00] Writing xtrabackup_binlog_info
180501 12:10:01 [00]        ...done
180501 12:10:01 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
mariabackup: The latest check point (for incremental): '2154617240383'
mariabackup: Stopping log copying thread.

2018-05-01 12:10:01 140057835345792 [Note] InnoDB: Read redo log up to LSN=2154583953920
180501 12:10:01 >> log scanned up to (2154583953920)
180501 12:10:01 Executing UNLOCK TABLES
180501 12:10:01 All tables unlocked
180501 12:10:01 [00] Copying ib_buffer_pool to /mnt/database_backups/test/ib_buffer_pool
180501 12:10:01 [00]        ...done
180501 12:10:01 Backup created in directory '/mnt/database_backups/test/'
MySQL binlog position: filename 'mariadb-bin.005485', position '28883329', GTID of the last change '0-1-241386'
180501 12:10:01 [00] Writing backup-my.cnf
180501 12:10:01 [00]        ...done
180501 12:10:01 [00] Writing xtrabackup_info
180501 12:10:01 [00]        ...done
mariabackup: Redo log (from LSN 2154583538384 to 2154583953920) was copied.
mariabackup: error: failed to copy enough redo log (LSN=2154583953920; checkpoint LSN=2154617240383).

有人可以解释问题可能是什么吗?我们的数据目录大约是94G,所以数据库非常大,你可以看到持续时间大约是17分钟。这与我们之前使用innobackupex的情况类似。

从上面的日志中可以看出,在备份的某个部分,有一些行以Executing FLUSH NO_WRITE_TO_BINLOG TABLES开头。我不确定这些是好还是有问题,但它们似乎有点奇怪,分散在数百条Copying行之间。下面列出的表实际上都是InnoDB,尽管它说Starting to backup non-InnoDB tables and files

感谢您的帮助。

1 个答案:

答案 0 :(得分:3)

我创建了Mariabackup 10.2。重做日志解析代码与Percona xtrabackup和Mariabackup 10.1有所不同。

您可以共享完整的日志,以便我们可以找出它失败的原因吗?如果您在https://jira.mariadb.org/提交了新的MDEV错误并在那里分享了详细信息,并在此处发布了该问题的链接,那么对我们来说将是最方便的。

我有两个假设。由于某个错误,重做日志的Copy_online会过早停止,或者有很多InnoDB后台活动会导致在备份结束后发出FLUSH TABLES WITH READ LOCK后写入重做日志。

无论哪种方式,Copy_last阶段似乎都无法复制剩余的日志,因为循环重做日志文件被覆盖了。

编辑:其他人就此问题提交了https://jira.mariadb.org/browse/MDEV-16367。如果您有更多信息,请在那里提交。

相关问题