浙江龙网

  1. 首页 > 生活百科 > >

基于案例分析 MySQL Group Replication 的故障检测流程( 四 )

生活百科


# mysql -h 192.168.244.3. -P 3306 -ut1 -p123456ERROR 3032 (HY000): The server is currently in offline mode

  • ABORT_SERVER：关闭实例 。
    • XCom CacheXCom Cache 是 XCom 使用的消息缓存 ， 用来缓存集群节点之间交换的消息 。缓存的消息是共识协议的一部分 。如果网络不稳定，可能会出现节点失联的情况 。
    如果节点在一定时间（由 group_replication_member_expel_timeout 决定）内恢复正常，它会首先应用 XCom Cache 中的消息 。如果 XCom Cache 没有它需要的所有消息，这个节点会被驱逐出集群 。驱逐出集群后，如果 group_replication_autorejoin_tries 不为 0 ， 它会重新加入集群（auto-rejoin） 。
    重新加入集群会使用 Distributed Recovery 补齐差异数据 。相比较直接使用 XCom Cache 中的消息 ， 通过 Distributed Recovery 加入集群需要的时间相对较长，过程也较复杂 ， 并且集群的性能也会受到影响 。
    所以，我们在设置 XCom Cache 的大小时，需预估 group_replication_member_expel_timeout + 5s 这段时间内的内存使用量 。如何预估，后面会介绍相关的系统表 。
    下面我们模拟下 XCom Cache 不足的场景 。
    1. 将group_replication_message_cache_size调整为最小值（128 MB），重启组复制使其生效 。
    mysql> set global group_replication_message_cache_size=134217728;Query OK, 0 rows affected (0.00 sec)mysql> stop group_replication;Query OK, 0 rows affected (4.15 sec)mysql> start group_replication;Query OK, 0 rows affected (3.71 sec)2. 将group_replication_member_expel_timeout调整为 3600 。这样 ， 我们才有充足的时间进行测试 。
    mysql> set global group_replication_member_expel_timeout=3600;Query OK, 0 rows affected (0.01 sec)3. 断开 node3 与node1、node2 之间的网络连接 。
    # iptables -A INPUT  -p tcp -s 192.168.244.10 -j DROP# iptables -A OUTPUT -p tcp -d 192.168.244.10 -j DROP# iptables -A INPUT  -p tcp -s 192.168.244.20 -j DROP# iptables -A OUTPUT -p tcp -d 192.168.244.20 -j DROP4. 反复执行大事务 。
    mysql> insert into slowtech.t1(c1) select c1 from slowtech.t1 limit 1000000;Query OK, 1000000 rows affected (10.03 sec)Records: 1000000  Duplicates: 0  Warnings: 05. 观察错误日志 。
    如果 node1 或 node2 的错误日志中提示以下信息 ， 则意味着 node3 需要的消息已经从 XCom Cache 中逐出了 。
    [Warning] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Messages that are needed to recover node 192.168.244.30:33061 have been evicted from the message  cache. Consider resizing the maximum size of the cache by  setting group_replication_message_cache_size.'6. 查看系统表 。
    除了错误日志 ， 我们还可以通过系统表来判断 XCom Cache 的使用情况 。
    mysql> select * from performance_schema.memory_summary_global_by_event_name where event_name like "%GCS_XCom::xcom_cache%"\G*************************** 1. row ***************************                  EVENT_NAME: memory/group_rpl/GCS_XCom::xcom_cache                 COUNT_ALLOC: 23678                  COUNT_FREE: 22754   SUM_NUMBER_OF_BYTES_ALLOC: 154713397    SUM_NUMBER_OF_BYTES_FREE: 28441492              LOW_COUNT_USED: 0          CURRENT_COUNT_USED: 924             HIGH_COUNT_USED: 20992    LOW_NUMBER_OF_BYTES_USED: 0CURRENT_NUMBER_OF_BYTES_USED: 126271905   HIGH_NUMBER_OF_BYTES_USED: 1461372941 row in set (0.00 sec)

    推荐阅读


    上一篇：系统整理K8S的配置管理实战-建议收藏系列

    下一篇：记录因Sharding Jdbc批量操作引发的一次fullGC