首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >使用innobackup 2.4遇到的问题

使用innobackup 2.4遇到的问题

作者头像
用户1278550
发布2018-08-09 10:21:39
7390
发布2018-08-09 10:21:39
举报
文章被收录于专栏:idbaidba

一 前言 Percona公司发布 innobackup 2.4 版本已经很久了,增加了新的特性比如支持非Innodb表备份,指定 --safe-slave-backup,增强备份的一致性,最重要的一点是支持5.7的备份,2.2是不能备份5.7 版本的。 考虑到以后我们要上线5.7 版本,因此我们决定将我们的percona的pt工具和备份软件更新到最新版本。本文主要记录我们使用 2.4 版本过程中遇到的问题和之前的一些改变。 二 问题和差异 2.1 backup-my.cnf 文件 innobackup 2.4版本比 之前的版本多了几个参数 2.2版本的内容

  1. [mysqld]
  2. innodb_checksum_algorithm=innodb
  3. innodb_log_checksum_algorithm=innodb
  4. innodb_data_file_path=ibdata1:12M:autoextend
  5. innodb_log_files_in_group=2
  6. innodb_log_file_size=1073741824
  7. innodb_page_size=16384
  8. innodb_log_block_size=512
  9. innodb_undo_directory=.
  10. innodb_undo_tablespaces=0

2.4 版本的内容

  1. [mysqld]
  2. innodb_checksum_algorithm=innodb
  3. innodb_log_checksum_algorithm=innodb
  4. innodb_data_file_path=ibdata1:12M:autoextend
  5. innodb_log_files_in_group=2
  6. innodb_log_file_size=1073741824
  7. innodb_page_size=16384
  8. innodb_log_block_size=512
  9. innodb_undo_directory=.
  10. innodb_undo_tablespaces=0
  11. server_id=0 # 2.4 新增参数
  12. redo_log_version=0 # 2.4 新增参数
  13. innodb_fast_checksum=false # 2.4 新增参数

这里强调一下 innodb_fast_checksum ,在applay log 之后依赖backup-my.cnf 启动MySQL的时候 5.6 是不能识别该参数的,导致启动失败。[ERROR] mysqld: unknown variable 'innodb_fast_checksum=0' 来看看2014年 相关的bug 说法 “Or maybe a separate feature request should be opened to copy the whole my.cnf to the backup directory as well. I will leave that up to others to decide.” 都3年了,都没有得出什么有效的结果。。其他地方的讨论,其实可以直接关闭。 https://dba.stackexchange.com/questions/6386/is-there-any-reason-not-to-use-percona-innodb-fast-checksum 2.2 场景 由于历史原因,我们还有部分数据库是是基于 mysqld_multi 做单机多实例的。这种单机多实例的配置文件有两种 /etc/my.cnf 和 /path/my.multi.cnf 两个配置文件。my.multi.cnf 文件里面配置了实例级别的个性参数。比如

  1. [mysqld_multi]
  2. mysqld=/usr/bin/mysqld_safe
  3. mysqladmin=/usr/bin/mysqladmin
  4. user=mysql
  5. log=/data/multi.log
  6. [3306]
  7. port = 3306
  8. datadir=/data/my3306
  9. socket=/data/my3306/mysql.sock
  10. user=mysql
  11. pid-file=/data/my3306/mysql.pid
  12. log=/data/my3306/mysqld.log
  13. [3307]
  14. port = 3307
  15. datadir=/data/my3307
  16. socket=/data/my3307/mysql.sock
  17. user=mysql
  18. pid-file=/data/my3307/mysql.pid
  19. log=/data/my3307/mysqld.log

innobackup 2.4 在备份时会去读 /etc/my.cnf ,如果该文件中没有配置server_id 则系统报错失败。如果没有/etc/my.cnf 则会去获取数据库实例配置的my.cnf 而不是 my.multi.cnf .. innobackupex: [ERROR] /usr/bin/innobackupex: Empty value for 'server-id' specified 解决方法回退到老的版本。 2.3 备份集文件内容的变化 我们的备份命令如下:

  1. /usr/bin/innobackupex --socket=/srv/my_3344/mysqld.sock --user=root --password= --no-timestamp --slave-info --rsync --compress --compress-threads=2 --parallel=1 /data/backup/rac1_3344/full/bk20170827105656 >/data/logs/zandb_agent/backup/rac1_3344_bk20170827105656.log 2>&1

使用了 compress 功能, 2.2版本的备份集压缩了数据库相关的数据文件

2.4版本的备份集文件

对自动化备份系统的影响是需要调整读取backup-my.cnf的步骤,必须在解压缩之后读取。 2.4 DDL 导致备份失败

MySQL 5.7 版本在使用Percona xtrabackup 2.4版本备份时执行ddl语句会导致备份失败。

[FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. Percona XtraBackup will not be able to take a consistent backup. Retry the backup operation

Bug fixed #1555626.

根本原因是

MySQL 5.7 can sometimes skip redo logging when creating an index. If such ALTER TABLE is being issued during the backup, the backup would be inconsistent. xtrabackup will now abort with error message if such ALTER TABLEhas been done during the backup. Bug fixed #1582345.

Percona Xtrabackup 提供了三个可选参数来规避这个问题,在备份命令加上以下参数之一

--lock-ddl, --lock-ddl-timeout, --lock-ddl-per-table 具体信息可以点击 阅读原文。

三 小结 这里例举了我们在使用新版本的备份软件遇到的问题,给其他准备使用的同行一些借鉴,也欢迎大家补充其他我们还没遇到的问题。

原文链接是Percona的blog 介绍备份期间执行DDL导致备份失败问题分析,有兴趣的可以认真阅读。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-10-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档