位置:编程技术网 > 架构设计 > 正文 >

全方位认识 MySQL 8.0 Group Replication

2020年10月03日 12:11来源:未知手机版

宁德婚纱摄影,海口旅行社,韩服游戏

巅峰赘婿

原标题:组复制性能|全方位认识MySQL8.0GroupReplication

本节介绍如何使用可用的系统变量对组复制进行性能优化,以便获得最佳性能。6.1.微调组通信线程当加载并启动MGR插件时,组通信线程(GCT)就会不断循环运行。GCT接收来自组和MGR插件的消息,处理与仲裁和故障检测相关的任务,发送一些保活的通讯消息,还处理MySQLServer与组之间传入和传出的事务。GCT会等待队列中的传入消息。当队列中没有消息时,GCT将会进行等待。在某些情况下,通过将这个等待配置得稍微长一些(进行主动等待),可以减少操作系统执行上下文切换时从处理器中换出GCT线程的次数。要强制GCT执行主动等待,请使用系统变量group_replication_poll_spin_loops进行设置,这使得GCT在对下一个消息进行实际轮询队列之前,在已配置的循环次数内进行循环时不做任何相关操作(该系统变量设置的值表示需要等待通信引擎互斥锁(mutex)被释放的次数,不是时间单位)。

mysql SETGLOBALgroup_replication_poll_spin_loops=10000;

6.2.流量控制组复制可确保事务仅在组中的大多数成员接收到它,且并发发送的所有事务在所有接收到事务的成员之间的相对顺序达成一致后,就可以执行事务的提交操作。如果对组的写入并发事务总数不超过组中任何成员的写入容量(提供写服务的能力),则此方法可以获得很好的性能。但如果组中所有成员能够提供的最大写服务能力不相同,那么组中服务能力低的成员可能出现数据延迟(例如:一些成员能提供3000TPS的写能力,但是有一些成员只能提供2000TPS的写能力),那么,当对能够提供3000TPS的成员写入并发3000的事务时,只能提供2000TPS的成员就会出现延迟(数据落后于能够提供3000TPS的成员)。组中如果有成员出现数据延迟,将有可能导致应用程序对这些成员执行读操作时,读取到非常陈旧的数据,另外,组中的其他不存在数据延迟的成员或多或少需要保存一些复制上下文(binlog日志记录),以满足来自存在数据延迟的慢速成员潜在的数据传输请求。但是,复制协议中有一种机制可以避免在快成员和慢成员之间存在过大的事务差距。这就是所谓的流量控制机制。流量控制机制图解决如下几个问题:

保持成员之间的数据足够接近(慢速成员没有太大数据延迟)。快速适应组中不断变化的环境。如,适应不同的工作负载或更多写操作。让组中的每个成员能够提供的写服务能力得到一个平衡。在非严格必要的情况下,不降低吞吐量,以避免浪费资源。考虑到组复制的设计,在决定是否需要启用流量控制时,可能要考虑两个工作队列:认证队列和二进制日志应用队列。当其中一个队列的大小超过用户定义的阈值时,就会触发流量控制机制。对于流量控制配置:首先,需要选择对谁配置流量控制,是对认证队列、还是针对应用队列、还是两者都需要配置流量控制。然后,对需要配置流量控制的对象(认证队列和应用队列)设置流量控制阈值。流量控制依赖于两个基本机制:对组成员进行监控,并收集所有组成员的吞吐量和队列大小的一些统计信息,从而对每个组成员能够承受的最大写压力进行有根据的猜测(评估);对组中的所有成员的并发写能力时刻保持监控,一旦某成员的并发压力超过了组中所有成员的平均写能力,就会对其执行流量控制。6.2.1.探测和统计监控机制通过在每个成员上部署一组探测器来收集关于其工作队列和吞吐量的信息。然后,将收集到的信息定期发送给组,以便与其他成员共享这些探测数据。这些探测器被分散在MGR插件的堆栈中,允许它们建立相应的度量指标,如下(这些指标值在performance_schema.replication_group_member_stats表中能够查询到):认证队列大小复制应用队列大小认证完成的事务总数组成员中应用的远程事务的总数本地事务的总数一旦一个成员收到来自另一个成员的带有统计信息的消息,它就会计算关于在最后一个监控探测期间,认证、应用和本地执行的事务数量等相关的度量指标。监控数据定期与组内其他成员共享。监控周期(频率)必须足够高,以便其他成员能够根据这些监控信息来确定当前的写请求量,但也必须足够低,以便对组带宽的影响最小。监控信息每秒钟都会被共享,一秒的时间间隔通常情况下能够解决这两个问题且能够很好地在这两个问题之间取得一个平衡。6.2.2.组复制节流组复制节流,指的是基于从组中所有成员中收集的度量指标,来决定是否启用限制成员"执行/提交'新事务的速度的一种节流机制。因此,从所有组成员获取的度量指标是计算每个组成员容量的基础:如果一个成员有一个大的队列(用于认证或复制应用线程),那么执行新事务的能力应该接近于上一阶段(最后一次探测时间段)认证或复制应用事务的能力。组中所有成员的最低容量(写能力)决定了组的实际容量,而本地事务的数量决定了有多少成员向其写入数据,因此也决定了应该与多少成员共享可用的容量。这意味着每个成员都有一个基于可用容量的写限额,换句话说,它就是下一个时间段内可以安全(不受节流机制影响)地执行的事务数量。如果认证队列或二进制日志应用队列大小超过用户定义的阈值,则将通过节流机制强制执行写限额。限额将根据上一阶段延迟的事务数量逐步减少10%,以让触发节流机制的队列大小减少到触发阈值以内。待到恢复后,为避免在队列大小超过阈值时出现吞吐量的陡增,在此之后,每个时间段的吞吐量只允许增长相同的10%。当前的节流机制不会对限额内的事务造成影响,但是会延迟完成那些超过限额的事务,直到监控周期结束。因此,如果写限额设置的非常小,一些事务的延迟可能会接近一个监控周期。6.3.消息压缩当网络带宽成为瓶颈时,消息压缩可以在组通信级别上将吞吐量提高达30-40%。这对于负载较大的大型组尤其重要。下表列出了在不同的二进制日志格式下的LZ4压缩率。工作负载模拟程序行格式压缩比例语句格式压缩比例mysqlslapd4,54,1sysbench3,42,9组中N个参与者之间的相互连接的TCP具有对等性质,使得发送方需要发送N次相同数量的数据(例如:组中有3个成员,那么发送方就要发送3次相同的数据)。此外,二进制日志可能具有较高的压缩比(见上表)。这使得压缩对于包含大事务的工作负载来说是一个引人注目的特性。在MGR插件中,支持压缩的是组通讯API组件,如下图。

本文地址:http://www.reviewcode.cn/jiagousheji/175697.html 转载请注明出处!

今日热点资讯