Mysql 组复制:永远卡在 RECOVERING 上
Posted
技术标签:
【中文标题】Mysql 组复制:永远卡在 RECOVERING 上【英文标题】:Mysql group replication: stuck on RECOVERING forever 【发布时间】:2018-06-11 09:41:44 【问题描述】:我有两个 mysql 服务器,它们在同一组复制上运行。 设置已通过以下步骤完成:
-
第一台服务器是具有大量数据的生产服务器。
我将其设置为只读并转储数据,然后在备用 MySQL 服务器上恢复它
恢复后,我执行“START GROUP_REPLICATION”并成功加入组。两台服务器之间的所有数据都可以很好地同步。
但我发现了另一个错误:每次我重新加载后备 MySQL(通过重新启动服务)时,它都会自动加入组但永远停留在 RECOVERING 中,我等了 3 天但它仍在 RECOVERING 中。 我检查了日志,在两台服务器上都没有看到任何错误,除了回退以只读方式运行并保持在 RECOVERING 之外,一切看起来都很好。
我错过了哪一步?
我的组配置是(我按照 DigitalOcean 帮助页面https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04 的说明进行操作):
BINARY LOGGING #log_bin = /data/databases/mysql_bin199 expire_logs_days = 14
sync_binlog = 1 binlog_format = 行
一般复制设置 gtid_mode = ON enforce_gtid_consistency = ON master_info_repository = TABLE relay_log_info_repository = TABLE binlog_checksum = NONE log_slave_updates = ON
log_bin = 二进制日志
binlog_format = ROW transaction_write_set_extraction = XXHASH64 松散组复制_bootstrap_group = OFF
loose-group_replication_start_on_boot = ON 松散组复制 SSL 模式 = 必需 松散组复制恢复使用ssl = 1
共享复制组配置loose-group_replication_group_name =
“9dc4ae01-6664-437a-83f8-80546d58e025” 松散组复制ip白名单= “172.AAA.BBB.166,138.AAA.BBB.199”松散组复制组种子 = "172.AAA.BBB.166:33061,138.AAA.BBB.199:33061"
单主模式还是多主模式?取消注释这两行
对于多主模式,任何主机都可以接受写入松散组复制_单主模式=关闭
loose-group_replication_enforce_update_everywhere_checks = ON
主机特定的复制配置 server_id = 2 report_host = "138.AAA.BBB.199" loose-group_replication_local_address =
“138.AAA.BBB.199:33061”
下面是第一台服务器上的 MySQL 日志:
2018-06-08T06:10:12.167400Z 0 [警告] 插件 group_replication
报告:'从组中删除的成员:138.AAA.BBB.199:3306'
2018-06-08T06:10:12.167475Z 0 [注意] 插件 group_replication
reported: '群组成员已更改为 172.AAA.BBB.166:3306 视图
15271181169364149:11。 2018-06-08T06:11:59.032666Z 0 [注意] 插件
group_replication 报告:'成员加入了组:
138.AAA.BBB.199:3306' 2018-06-08T06:11:59.032722Z 0 [注意] 插件 group_replication 报告:'组成员更改为
172.AAA.BBB.166:3306、138.AAA.BBB.199:3306 在视图 15271181169364149:12.'
以下是备用服务器上的 MySQL 日志:
2018-06-11T09:22:57.490896Z 0 [警告] 选项“max_allowed_packet”:
无符号值 3221225472 调整为 1073741824
2018-06-11T09:22:57.490942Z 0 [警告] InnoDB 的使用是强制性的
从 MySQL 5.7 开始。前一个选项,如 '--innodb=0/1/OFF/ON' 或
'--skip-innodb' 被忽略。 2018-06-11T09:22:57.491057Z 0 [警告]
语法 '--log_warnings/-W' 已被弃用,将被删除
未来版本。请改用“--log_error_verbosity”。
2018-06-11T09:22:57.491098Z 0 [警告] TIMESTAMP 隐含
DEFAULT 值已弃用。请使用
--explicit_defaults_for_timestamp 服务器选项(有关详细信息,请参阅文档)。 2018-06-11T09:22:57.492972Z 0 [注意] /usr/sbin/mysqld
(mysqld 5.7.22-log) 从进程 31633 开始 ...
2018-06-11T09:22:57.500063Z 0 [警告] InnoDB:使用
innodb_locks_unsafe_for_binlog 已弃用。这个选项可能是
在未来的版本中被移除。请使用 READ COMMITTED 事务
改为隔离级别;请参考
http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html
2018-06-11T09:22:57.500175Z 0 [注意] InnoDB:打孔支持
可用 2018-06-11T09:22:57.500191Z 0 [注意] InnoDB:互斥锁和
rw_locks 使用 GCC atomic builtins 2018-06-11T09:22:57.500200Z 0 [注意]
InnoDB:使用事件互斥锁 2018-06-11T09:22:57.500205Z 0 [注意]
InnoDB:GCC 内置 __atomic_thread_fence() 用于内存屏障
2018-06-11T09:22:57.500209Z 0 [注意] InnoDB:压缩表使用
zlib 1.2.3 2018-06-11T09:22:57.500213Z 0 [注意] InnoDB:使用 Linux
本机 AIO 2018-06-11T09:22:57.500430Z 0 [注意] InnoDB:数量
池:1 2018-06-11T09:22:57.500575Z 0 [注意] InnoDB:使用 CPU crc32
说明 2018-06-11T09:22:57.501015Z 0 [错误] InnoDB: 失败
创建检查扇区文件,errno:13 请确认O_DIRECT是
支持并删除文件 /data/check_sector_size(如果存在)。
2018-06-11T09:22:57.502305Z 0 [注意] InnoDB:初始化缓冲池,
总大小 = 4G,实例 = 8,块大小 = 128M
2018-06-11T09:22:57.799065Z 0 [注意] InnoDB:已完成初始化
缓冲池 2018-06-11T09:22:57.857325Z 0 [注意] InnoDB:如果
mysqld执行用户授权,页面清理线程优先级可以
改变。请参阅 setpriority() 的手册页。
2018-06-11T09:22:57.870317Z 0 [注意] InnoDB:支持的最高文件
格式是梭子鱼。 2018-06-11T09:22:58.081570Z 0 [注意] InnoDB:
为临时表创建共享表空间
2018-06-11T09:22:58.081656Z 0 [注意] InnoDB:设置文件
'/data/databases/ibtmp1' 大小为 12 MB。物理写入文件
满的;请稍候... 2018-06-11T09:22:58.116190Z 0 [注意] InnoDB:
文件 '/data/databases/ibtmp1' 大小现在为 12 MB。
2018-06-11T09:22:58.117279Z 0 [注意] InnoDB:96 次重做回滚
找到了段。 96 个重做回滚段处于活动状态。
2018-06-11T09:22:58.117293Z 0 [注意] InnoDB:32 次非重做回滚
段处于活动状态。 2018-06-11T09:22:58.117670Z 0 [注意] InnoDB:
等待清除开始 2018-06-11T09:22:58.168094Z 0 [注意]
InnoDB:5.7.22 开始;日志序列号51745666191
2018-06-11T09:22:58.168309Z 0 [注意] InnoDB:加载缓冲池
来自 /data/databases/ib_buffer_pool 2018-06-11T09:22:58.168558Z 0
[注意] 插件“FEDERATED”已禁用。 2018-06-11T09:22:58.183268Z 0
[警告] CA 证书 /etc/mysql/mysql-ssl/ca-cert.pem is self
签名。 2018-06-11T09:22:58.184615Z 0 [注意] 服务器主机名
(绑定地址): '138.AAA.BBB.199';端口:3306
2018-06-11T09:22:58.184636Z 0 [注意] - '138.AAA.BBB.199' 解析为
'138.AAA.BBB.199'; 2018-06-11T09:22:58.184668Z 0 [注意] 服务器套接字
在 IP:“138.AAA.BBB.199”上创建。 2018-06-11T09:22:58.186203Z 0
[警告] 'user' entry 'mysql.session@localhost' 被忽略
--跳过名称解析模式。 2018-06-11T09:22:58.186220Z 0 [警告] 'user' 条目 'mysql.sys@localhost' 在 --skip-name-resolve 中被忽略
模式。 2018-06-11T09:22:58.186238Z 0 [警告]“用户”条目
'phpmadsys@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186260Z 0 [警告]“用户”条目
'phpmyadmin@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186308Z 0 [警告] 'db' entry 'performance_schema
mysql.session@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186313Z 0 [警告] 'db' entry 'sys
mysql.sys@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186318Z 0 [警告] 'db' entry 'phpmyadmin
phpmadsys@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186322Z 0 [警告] 'db' entry 'performance_schema
datadog@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186327Z 0 [警告] 'db' entry 'phpmyadmin
phpmyadmin@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.186340Z 0 [警告] 'proxies_priv' 条目 '@
root@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.188628Z 0 [警告]“tables_priv”条目“用户”
mysql.session@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.188649Z 0 [警告] 'tables_priv' 条目
'sys_config mysql.sys@localhost' 在 --skip-name-resolve 模式下被忽略。
2018-06-11T09:22:58.192624Z 0 [警告] --relay-log 和
--relay-log-index 被使用;因此,当此 MySQL 服务器充当从属服务器并更改其主机名时,复制可能会中断!请使用
'--relay-log=dvm02-relay-bin' 来避免这个问题。
2018-06-11T09:22:58.206545Z 0 [注意] 事件调度程序:加载 0 个事件
2018-06-11T09:22:58.206745Z 0 [注意] /usr/sbin/mysqld: 准备好了
连接。版本:'5.7.22-log' 套接字:
'/var/run/mysqld/mysqld.sock' 端口:3306 MySQL 社区服务器
(GPL) 2018-06-11T09:22:58.207175Z 2 [注意] 插件 group_replication
reported: '群组通信 SSL 配置:
group_replication_ssl_mode:“需要”; server_key_file:
"/etc/mysql/mysql-ssl/server-key.pem"; server_cert_file:
"/etc/mysql/mysql-ssl/server-cert.pem";客户端密钥文件:
"/etc/mysql/mysql-ssl/server-key.pem";客户端证书文件:
"/etc/mysql/mysql-ssl/server-cert.pem"; ca_file:
"/etc/mysql/mysql-ssl/ca-cert.pem"; ca_path: "";密码:“”;
tls_version: "TLSv1,TLSv1.1"; crl_file: ""; crl_path: ""'
2018-06-11T09:22:58.207378Z 2 [警告] 插件 group_replication
reported: '[GCS] 自动添加 IPv4 localhost 地址到
白名单。必须添加它。'
2018-06-11T09:22:58.207820Z 2 [注意] 插件 group_replication
reported: '使用配置初始化组通信:
group_replication_group_name: "9dc4ae01-6664-437a-83f8-80546d58e025";
group_replication_local_address: "138.AAA.BBB.199:33061";
group_replication_group_seeds:
"172.AAA.BBB.166:33061,138.AAA.BBB.199:33061";
group_replication_bootstrap_group: false;
group_replication_poll_spin_loops:0;
group_replication_compression_threshold: 1000000;
group_replication_ip_whitelist: "172.AAA.BBB.166,138.AAA.BBB.199"'
2018-06-11T09:22:58.207853Z 2 [注意] 插件 group_replication
reported: '[GCS] 配置的加入尝试次数:0'
2018-06-11T09:22:58.207859Z 2 [注意] 插件 group_replication
reported: '[GCS] 尝试加入的配置时间间隔:5 秒'
2018-06-11T09:22:58.207878Z 2 [注意] 插件 group_replication
reported: '会员配置:member_id: 2; member_uuid:
"822868f9-52a0-11e8-aa0e-1e45f9551f27";单主模式:“假”;
group_replication_auto_increment_increment:7; '
2018-06-11T09:22:58.209024Z 3 [Note] 'CHANGE MASTER TO FOR CHANNEL
'group_replication_applier'已执行'。以前的状态
master_host='', master_port= 0, master_log_file='',
master_log_pos=4,master_bind=''。新状态 master_host='',
master_port=0,master_log_file='',master_log_pos=4,master_bind=''。
2018-06-11T09:22:58.216904Z 6 [注意] 通道的 Slave SQL 线程
'group_replication_applier' 已初始化,在日志中开始复制
'FIRST' 在位置 0,中继日志
'./dvm02-relay-bin-group_replication_applier.000071' 位置:4
2018-06-11T09:22:58.216931Z 2 [注意] 插件 group_replication
reported: 'Group Replication 应用程序模块已成功初始化!'
2018-06-11T09:22:58.241357Z 0 [注意] 插件 group_replication
报告:'XCom 协议版本:3' 2018-06-11T09:22:58.241397Z 0
[注意] 插件 group_replication 报告:'XCom 已初始化并准备就绪
接受端口 33061' 上的传入连接
2018-06-11T09:22:59.213826Z 0 [注意] InnoDB:缓冲池加载
完成于 180611 11:22:59 2018-06-11T09:23:00.316791Z 0 [注]
插件 group_replication 报告:'组成员更改为
172.AAA.BBB.166:3306、138.AAA.BBB.199:3306 在视图 15271181169364149:16.'
【问题讨论】:
【参考方案1】:抱歉耽搁了。
从您的错误日志中,我看不到任何有关恢复的问题,但我也看不到任何连接尝试。我想知道您是否对组复制中继日志中的数据有一些问题...
如果问题仍然存在,我建议您打开一个错误。 作为一种解决方法,您可以尝试在“START GROUP_REPLICATION”之前重置应用程序通道
RESET SLAVE ALL FOR CHANNEL "group_replication_applier";
【讨论】:
重置是否会对我的数据造成任何问题?后备服务器是否有来自主服务器的最新数据? 重置可能会清除过去收到但在此成员上运行组复制时尚未应用的数据。如果组内的在线成员拥有所有数据,则不会丢失任何数据。以上是关于Mysql 组复制:永远卡在 RECOVERING 上的主要内容,如果未能解决你的问题,请参考以下文章
linux报错:/dev/sdb2:recovering journal
电脑开机一直出现recovering orphaned file是怎么回事,要怎么解决