MySQL 8.0.14版本增加了一个新特性:MGR读写一致性;有了此特性,“妈妈”再也不用担心读MGR非写节点数据会产生不一致啦。
有同学会疑问:“MGR不是'全同步'么,也会产生读写不一致?”,在此肯定的告诉大家MGR会产生读写不一致,原因如下:
MGR相对于半同步复制,在relay log前增加了冲突检查协调,但是binlog回放仍然可能延时,也就是跟我们熟悉的半同步复制存在io线程的回放延迟情况类似。当然关于IO线程回放慢的原因,跟半同步也类似,比如大事务!!
所以MGR并不是全同步方案,关于如何处理一致性读写的问题,MySQL 在8.0.14版本中加入了“读写一致性”特性,并引入了参数:group_replication_consistenc,下面将对读写一致性的相关参数及不同应用场景进行详细说明。
参数group_replication_consistenc的说明
group_replication_consistency 参数可以用法SESSION,GLOBAL去进行更改。
官方说明请参考:
https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html
官方引入的MGR读写一致性既有它自身的天然优势,也不可避免的存在相应的不足,其优缺点如下:
在实际应用中需要大家因地制宜,根据实际情况选择最适配的方案。
针对不同应用场景应当如何选择MGR读写一致性的相关方式,官方提供了几个参数以及与其相对应的应用场景:
适用场景1:
写少读多的场景进行读写分离,担心读取到过期事务,可选择AFTER。
适用场景2:只读为主的集群,有RW的事务需要保证提交的事务能被其他后序事务读到最新读数据,可选择AFTER。
适用场景1:应用大量写入数据,偶尔进行读取一致性数据,应当选择BEFORE。
适用场景2:有特定事务需要读写一致性,以便对敏感数据操作时,始终读取最新的数据;应当选择BEFORE。
适用场景:有一个读为主的集群,有RW的事务既要保证读到最新的数据,又要保证这个事务提交后,被其他后序事务读到;在这种情况下可选择BEFORE_AND_AFTER。
举例1:某一事务语句,需要其他节点的数据强一致性。可以使用SET@@SESSION.group_replication_consistency= ‘AFTER’进行设置。
举例2:跟例1相似,在每天执行分析语句事务并且需要获得读取新数据的情况下。
可以使用SET @@SESSION.group_replication_consistency= ‘BEFORE’ 进行设置
扫码加入QQ技术交流群
(群号:793818397)