一次使用innobackupex重新搭建主从复制报错解决方法及注意事项

【环境介绍】

系统环境:CentOS release 6.4 (Final) + Server version: 5.7.18-log MySQL Community Server (GPL) + innobackupex version 2.4.12 Linux (x86_64)

【背景描述】

使用innobackupex重新全备搭建主从复制步骤简单,但是由于历史原因在全备恢复后出现报错:。

[ERROR] InnoDB: Unable to open undo tablespace ‘.//undo001‘.
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin ‘InnoDB‘ init function returned error.
[ERROR] Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.

【实施步骤】

主库操作:

主库备份全库

innobackupex --defaults-file=/etc/my.cnf --user=root --password=mysql -S /tmp/mysql.sock  /root/backup

[[email protected] backup]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=mysql -S /tmp/mysql.sock  /root/backup
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql/data --server-id=101 --open_files_limit=65535 --tmpdir=/home/mysql/tmp --innodb_buffer_pool_size=1G --innodb_flush_log_at_trx_commit=1 --innodb_undo_tablespaces=3 -

......》》》省略输出内容

xtrabackup: Transaction log of lsn (2458487) to (2458496) was copied.
181222 04:40:18 completed OK!
[[email protected] backup]#

将备份文件拷贝至备库

[[email protected] backup]# tar -cvf 2018-12-22_04-39-56.tar 2018-12-22_04-39-56/
2018-12-22_04-39-56/
....》》省略部分
2018-12-22_04-39-56/sys/[email protected]_summary_by_statement_type.frm
[[email protected] backup]#

[[email protected] backup]# scp 2018-12-22_04-39-56.tar 192.168.8.100:/root/backup/
[email protected]‘s password:
2018-12-22_04-39-56.tar                                                                                                                                    100%  299MB  37.4MB/s   00:08   
[[email protected] backup]#

备库操作:

关闭数据库

[[email protected] mysql]# mysqladmin --defaults-file=/etc/my.cnf --protocol=tcp -P3306 shutdown -uroot -pmysql
[[email protected] mysql]#
[1]+  Done                    mysqld --defaults-file=/etc/my.cnf --user=mysql  (wd: ~)
(wd now: /var/lib/mysql)
[[email protected] mysql]#
备份原库数据
[[email protected] mysql]# ls -trl
total 56
drwxr-xr-x.  6 mysql mysql  4096 Dec 22 08:47 data
[[email protected] mysql]# mv data data_bak

进行全库恢复

进行--apply-log操作

[[email protected] mysql]# innobackupex --defaults-file=/etc/my.cnf  --apply-log /root/backup/2018-12-22_04-39-56
xtrabackup: recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksum_algorithm=strict_crc32 --innodb_data_file_path=ibdata1:256M:autoextend --innodb_log_files_in_group=2 --

....》》省略部分

InnoDB: Shutdown completed; log sequence number 2459176
181222 08:52:03 completed OK!
[[email protected] mysql]#

进行--copy-back操作

[[email protected] mysql]# innobackupex --defaults-file=/etc/my.cnf  --copy-back /root/backup/2018-12-22_04-39-56
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql/data --server-id=100 --open_files_limit=65535 --tmpdir=/home/mysql/tmp --innodb_buffer_pool_size=1G --innodb_flush_log_at_trx_commit=1 --innodb_log_buffer_size=32M -

....》》省略部分

181222 08:53:24 [01]        ...done
181222 08:53:24 completed OK!
[[email protected] mysql]#

修改数据文件目录权限

[[email protected] mysql]# chown -R mysql:mysql   data

直接启动数据库

[[email protected] mysql]#mysqld --defaults-file=/etc/my.cnf --user=mysql &

查看日志出现报错:

2018-12-22T13:56:08.963837Z 0 [Warning] option ‘table_definition_cache‘: unsigned value 64 adjusted to 400
2018-12-22T13:56:09.138266Z 0 [Warning] option ‘max_binlog_size‘: unsigned value 2147483648 adjusted to 1073741824
2018-12-22T13:56:09.138392Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-12-22T13:56:09.138450Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.
2018-12-22T13:56:09.138502Z 0 [Note] mysqld (mysqld 5.7.18-log) starting as process 4873 ...
2018-12-22T13:56:09.197459Z 0 [Note] InnoDB: PUNCH HOLE support not available
2018-12-22T13:56:09.197501Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-12-22T13:56:09.197513Z 0 [Note] InnoDB: Uses event mutexes
2018-12-22T13:56:09.197525Z 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
2018-12-22T13:56:09.197536Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-12-22T13:56:09.197547Z 0 [Note] InnoDB: Using Linux native AIO
2018-12-22T13:56:09.198473Z 0 [Note] InnoDB: Number of pools: 1
2018-12-22T13:56:09.198675Z 0 [Note] InnoDB: Using CPU crc32 instructions
2018-12-22T13:56:09.200901Z 0 [Note] InnoDB: Initializing buffer pool, total size = 1G, instances = 1, chunk size = 128M
2018-12-22T13:56:09.400867Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-12-22T13:56:09.408553Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-12-22T13:56:09.494523Z 0 [ERROR] InnoDB: Unable to open undo tablespace ‘.//undo001‘.
2018-12-22T13:56:09.494551Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2018-12-22T13:56:10.101405Z 0 [ERROR] Plugin ‘InnoDB‘ init function returned error.
2018-12-22T13:56:10.101433Z 0 [ERROR] Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.
2018-12-22T13:56:10.101443Z 0 [ERROR] Failed to initialize plugins.
2018-12-22T13:56:10.101451Z 0 [ERROR] Aborting

2018-12-22T13:56:10.101465Z 0 [Note] Binlog end
2018-12-22T13:56:10.101521Z 0 [Note] Shutting down plugin ‘CSV‘
2018-12-22T13:56:10.102134Z 0 [Note] mysqld: Shutdown complete

【问题解决】

从以上报错发现无法打开undo tablespace undo001,查看备库数据目录查看,确实不存在undo001,查看主库存在undo001表空间。

从恢复日志看--apply-log的时候石有undo表空间的信息

InnoDB: Opened 3 undo tablespaces
InnoDB: 3 undo tablespaces made active

从恢复日志看--copy-back的时候并没有拷贝undo表空间的信息。思考为啥没有copy的undo表空间到数据目录信息

innobackupex --defaults-file=/etc/my.cnf  --apply-log /root/backup/2018-12-22_04-39-56

根据思路从命令恢复的可以看出涉及两个文件确认undo表空间信息/etc/my.cnf,/root/backup/2018-12-22_04-39-56

[[email protected] ~]# cat /etc/my.cnf |grep undo
[[email protected] ~]# ls -trl /root/backup/2018-12-22_04-39-56|grep undo
-rw-r-----. 1 root root  10485760 Dec 22 08:51 undo003
-rw-r-----. 1 root root  10485760 Dec 22 08:51 undo002
-rw-r-----. 1 root root  10485760 Dec 22 08:51 undo001
[[email protected] ~]#

从上面的结果可以看出备份文件中是存在undo表空间且是3个undo表空间,但是从参数文件中不存在undo表空间的信息

至此可以初步断定为参数文件中没有指定undo表空间信息,于是在配置文件中添加innodb_undo_tablespaces=3,再次--apply-log操作

观察日志信息,已经存在undo拷贝操作

innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
181223 03:09:12 [01] Copying undo001 to /var/lib/mysql/data/undo001
181223 03:09:12 [01]        ...done
181223 03:09:12 [01] Copying undo002 to /var/lib/mysql/data/undo002
181223 03:09:13 [01]        ...done
181223 03:09:13 [01] Copying undo003 to /var/lib/mysql/data/undo003
181223 03:09:13 [01]        ...done
181223 03:09:14 [01] Copying ib_logfile0 to /var/lib/mysql/data/ib_logfile0
181223 03:09:15 [01]        ...done
181223 03:09:15 [01] Copying ib_logfile1 to /var/lib/mysql/data/ib_logfile1

于是手工再次启动数据库,数据库正常拉起,没有undo报错,继续搭建主从复制。

【错误日志warring】

2018-12-22T13:56:08.963837Z 0 [Warning] option ‘table_definition_cache‘: unsigned value 64 adjusted to 400
2018-12-22T13:56:09.138266Z 0 [Warning] option ‘max_binlog_size‘: unsigned value 2147483648 adjusted to 1073741824
2018-12-22T13:56:09.138392Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-12-22T13:56:09.138450Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.

根据5.7官方文档对应参数调整如下:

table_definition_cache默认值为400,可以调整400 + (table_open_cache / 2)

max_binlog_size=1024M

explicit_defaults_for_timestamp = ON

secure_file_priv =  " "

【主从复制搭建】

[[email protected] 2018-12-22_04-39-56]# cat xtrabackup_binlog_info
binlog.000011   489     2478c036-bd7a-11e8-85df-080027206a62:5-6,fbfd9bcb-0437-11e9-947d-080027206a62:1-9
[[email protected] 2018-12-22_04-39-56]#

mysql> reset master;
Query OK, 0 rows affected (0.12 sec)

mysql> set global gtid_purged=‘2478c036-bd7a-11e8-85df-080027206a62:5-6,fbfd9bcb-0437-11e9-947d-080027206a62:1-9‘;
Query OK, 0 rows affected (0.00 sec)

mysql> change master to master_user= ‘repl‘,master_host=‘192.168.8.101‘,master_password=‘repl‘,master_port=3306,MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.48 sec)

mysql> start slave;
Query OK, 0 rows affected (0.04 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.8.101
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000013
          Read_Master_Log_Pos: 234
               Relay_Log_File: mysqldb1-relay-bin.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000013
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

........省略部分输出内容

Executed_Gtid_Set: 2478c036-bd7a-11e8-85df-080027206a62:5-6,fbfd9bcb-0437-11e9-947d-080027206a62:1-9
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

mysql>

测试数据同步正常

【总结】

innobackupex备份恢复前确认主库跟恢复库的参数一致,可以使用diff命令查看参数的必要性;

可能由于历史原因参数没有写到配置文件报错,应该做好工程修改记录对于问题查找有很大的作用。

原文地址:https://www.cnblogs.com/zetanchen/p/10164807.html

时间: 2024-11-10 13:35:29

一次使用innobackupex重新搭建主从复制报错解决方法及注意事项的相关文章

zabbix源码安装流程及报错解决方法

zabbix源码安装流程及报错解决方法 一. zabbix的介绍 1) zabbix是什么 zabbix是一款基于web页面的.开源的.企业级的,支持分布式部署的监控软件. 2)2.zabbix的作用 监控windows和Linux主机上的软硬件状态. 监控各网络设备,如路由器.交换机.防火墙.f5.打印机等. 支持邮件短信微信等平台发送告警通知. 通过web页面及图形展示监控数据. 3)zabbix的特性 由zabbix server和agent程序协同工作,还支持分布式监控,这时需要安装za

node-sass报错解决方法

node-sass报错解决方法 node-sass报错解决方法 在Vue.js中,每一个vue文件都是一个组件,在.vue文件中可以将模板,脚本,样式写在一起,便于组织整个组件.在使用template,script时,编写css样式时,都进行的特别顺利,唯独当我想用sass来预处理css时,在style下使用lang='sass'一直报错. 在.vue中是这样的. <template > <div class="haha"> <p> keith +

报错解决方法Error: Can&#39;t connect to local MySQL server through socket

Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)Errno.: 2002解决方法一:因为你还没有启动mysql,当你启动mysql后,mysql.sock就会自动的生成../bin/safe_mysqld   --user=root   &(这是默认的).如果还没有,就是MYSQL权限没给,或其它原因还有就是 你的mysql是否启动了      启动后一般很难出现这个

PS win7_无法打开提示MSVCP120.dll报错解决方法

PS win7_无打开提示MSVCP120.dll报错解决方法 1.PS软件安装后无法打开,并提示MSVCP120.dll"ps无法启动此程序此 因为计算机中丢失msvcp120.dll" 报错提示: 问题解决方法: 下载DirectX Repair工具-安装并运行即可,会自动检测是否丢失msvcp120.dll等一系列套件. 提示图片: 下载链接:http://www.pc6.com/softview/SoftView_57945.html 注:根据自己本身使用系统版本,下载Dire

putty生成密钥SSH远程登录注意步骤及报错解决方法

putty生成密钥SSH远程登录注意步骤及报错解决方法 报"Putty server refused our key"(解决)排查步骤: 1..ssh文件夹权限和authorized_keys文件权限 1-1创建.SSH目录及authorized_keys文件 mkdir –p /root/.ssh touch authorized_keys 1-2 修改目录及文件权限 Chmod 700 .ssh Chmod 600 authorized_keys 2. Selinux安全机制和Ip

远程连接Windows Server 2012 R2虚拟机报错解决方法

前两天在公司通过TeamViewer连回家里做实验时发现,连到某一台二代虚机时登陆会弹出一个错误提示,内容如下: 经过测试发现,只要是切换到普通模式(非增强模式)就可以正常登陆进系统,但是只要切换到特权模式就会出现这样的错误,开始以为是远程登陆的错误,查看后发现远程连接一切正常,权限方面也已经加进去了,那为什么增强模式下登陆就会出错呢? 在组策略里找了找也没发现答案,之后突然惊觉这个账户并不是本地的管理员,也不在域管理员组里,只是一个普通用户,是不是因为这点呢?运行管理员权限的命令提示符之后.输

运行Tomcat报错 解决方法

运行Tomcat报错 解决方法 运行Tomcat控制台报错: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jdk1.6.0_26/jre/lib/i386/server:/usr/local/jdk1.6.0_26/jre/lib/i3

c# winform 引用sqlite.dll 运行报错解决方法

错误信息 :  未能加载文件或程序集“System.Data.SQLite, Version=1.0.81.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139”或它的某一个依赖项.试图加载格式不正确的程序. 原因是 此sqlite.dll 是32位的. 解决方法 ,将项目的 目标平台改为 x86 如图 c# winform 引用sqlite.dll 运行报错解决方法

Loadrunner参数化逗号报错解决方法

Loadrunner参数化逗号报错解决方法 介绍Loadrunner参数化时,参数中包含有逗号时出错的解决方法. 在Loadrunner进行参数化时,参数中如果含有逗号,编辑保存后会报错: 此时对英文逗号进行转义即可正常进行参数化: 参数化方法即添加双引号进行转义: 如123456abc","即表示参数123456abc,