我正在运行一个具有三个节点的测试集群 - db-[1-3]。这三个人都是单个主组复制集群的快乐成员。它们都配置有group_replication_start_on_boot=on
. 在无人值守升级(..现已被禁用)之后,他们都陷入了故障模式,因为dpkg
无法正确升级软件包;它被困在一个 futex 锁上,永远等待。然后我的测试集群就死了,因为所有三个节点在几天内都陷入了升级锁定。
我能够通过切换group_replication_start_on_boot
到 来纠正问题off
,这意味着dpkg
能够apt
升级系统并重新启动 MySQL 守护进程。然而,这破坏了我的组复制集群,因为升级过程在每个节点上本地运行一条 SQL 语句作为升级过程的一部分,该语句被插入到 binlog 中 - 现在每个节点都认为它领先于所有其他节点,因为它们已经binlog中未同步到其他节点的本地语句。
在深入挖掘二进制日志后,我发现每台服务器上本地发出的语句都是相同的,因此我可以安全地忽略它们:
mysql> show binlog events in 'binlog.000010';
+---------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------------------+
| binlog.000010 | 4 | Format_desc | 2 | 126 | Server ver: 8.0.33-0ubuntu0.22.04.1, Binlog ver: 4 |
| binlog.000010 | 126 | Previous_gtids | 2 | 253 | 3ae6293d-dfc6-4896-af5d-92963a090e0e:15-195:1000035-1000037,
3f11c191-ca88-11ed-89cf-fa163ea3e6a7:1 |
| binlog.000010 | 253 | Gtid | 2 | 330 | SET @@SESSION.GTID_NEXT= '3f11c191-ca88-11ed-89cf-fa163ea3e6a7:2' |
| binlog.000010 | 330 | Query | 2 | 477 | use `mysql`; ALTER USER 'root'@'localhost' IDENTIFIED WITH 'auth_socket' /* xid=3 */ |
+---------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)
我假设3f11c191-ca88-11ed-89cf-fa163ea3e6a7
GTID 破坏了主节点和该节点之间的状态信息。
然而,这留下了一点不好的味道,因为我希望将来能够升级 MySQL 服务器版本,但我最终得到了一个损坏的集群。这可能是一种特殊情况,因为当所有三个节点都不可用时,集群实际上已死亡。
我希望将来避免这种情况,所以问题有两个:
如果我以后group_replication_start_on_boot
运行前手动禁用apt upgrade
,那么下次启动组复制时事务是否会正确同步?(我猜它不会,因为它将在本地进行主服务器没有的事务)
..如果没有,在运行基于组复制的节点集群时,处理基于分布的升级的推荐方法是什么?如果升级节点后必须手动将主节点上已用的 gtid 清零,如何以不会导致停机的方式升级集群?
不,不是单独的,我已经尝试过这个,但是 deb 包中的脚本总是对 mysql.user 进行一些修改
我发现的最佳解决方案是在升级之前禁用启动时的复制
loose-group_replication_start_on_boot = OFF
,并使用此处的解决方案:在升级过程中禁用 mysql 数据库的 binlog 的服务器故障。引用解决方案:您还可以选择不一起复制 mysql 数据库。