随着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 很可能可以自动重新加入，不在依赖手工进行加载。
发展的速度太快，一步跟不上，步步跟不上。
