我们最近从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条答案
按热度按时间nwlls2ji1#
我创建了mariabackup 10.2。redo日志解析代码与percona xtrabackup和mariabackup 10.1有些不同。
你能分享完整的日志吗,这样我们就可以找出它失败的原因了?对我们来说,如果你在https://jira.mariadb.org/ 在那里分享了细节,并在这里发布了问题的链接。
我有两个假设。要么是redo log的copy\u online由于一个bug而过早停止,要么是innodb的后台活动太多,导致redo log在备份之后被写入
FLUSH TABLES WITH READ LOCK
已在备份即将结束时发出。无论哪种方式,似乎都有可能是复制最后阶段无法复制剩余的日志,因为循环重做日志文件在这两个阶段之间被覆盖。
编辑:其他人提交https://jira.mariadb.org/browse/mdev-16367 对于这个问题。如果你有更多的信息,请在那里提交。