随着MYSQL 8 越来越成熟,未来MYSQL 将会开始替换 MYSQL 5.7X成为新的MYSQL 数据库在市面上的主力。
而MYSQL 8 在 P_S (performance_schema)中的一些变化,以及如何更好的monitor MGR 这是一个值得去学习的地方。
在MYSQL 8 后P_S 引入了 XCOM, GCS两个信息,这主要是要增加MGR的可观测性和管理性。
1 在thread中引入了部分Xcom GCS 信息,
这四个线程主要启动的作用
Gcs_ext_logger_impl::m_consumer
处理有关任何触发点后的日志信息记录线程
Gcs_xcom_engine::m_engine_thread 处理GCS 中的事件线程
Gcs_xcom_control::m_xcom_thread
负责xcom的运行线程
Gcs_xcom_control::m_suspicions_processing_thread 处理意外情况驱逐节点的线程
2 在等待事件表中也可以查看关于这两方面的等待信息
首先我们需要打开相关的等待时间的记录开关
在打开后,我们可以通过查看相关的等待记录,或历史等待记录,来了解MGR 在使用过程中有哪些问题细节。具体哪些等待事件对应哪些问题,可以通过查看官方文档来解决。
并且在 Replication_group_member_stats
中在MYSQL 8 添加了一些字段
1 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE
从接收组中的事务在等待队列
2 COUNT_TRANSACTIONS_REMOTE_APPLIED
成员已经从应用组中应用的事务
3 COUNT_TRANSACTION_LOCAL_PROPOSED
群组中协同的事务数量
4 COUNT_TRANSACTION_LOCAL_ROLLEDBACK
群组中进行rollback的事务数量、
并且最近从爱可生发布的文章,中提到了Large Messages Fragmentation Layer for Group Replication,这是对于MGR中被人提到的大事务造成的MGR 主机离线的问题的一个解决方法,通过对事务打散后在重新组装的方式来进行大事务的集群化的处理。
除此之外MYSQL 8.016 还在,同时 XCom’s message cache 不在是绑定一个静态的数字,而是开始进行动态的设定根据消息的大小开始变化。
而最新的8.016版本支持 Auto-rejoin for Group Replication,未来新版本中被踢出的MYSQL 很可能可以自动重新加入,不在依赖手工进行加载。
发展的速度太快,一步跟不上,步步跟不上。
本文分享自 AustinDatabases 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!