MySQL中GTID追踪的自适应路由查询是怎样的,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
基于GTID追踪的自适应路由查询
ProxySQL是一个工作在第七层(应用层)且支持MySQL协议的的数据库代理,ProxySQL本身自带了高可用和高性能的功能,并且包含了丰富的功能集。在即将到来的2.0版本中的功能将会更加兴奋!
ProxySQL中最常用的功能当属查询的分析统计和基于路由查询做到的读写分离。
当客户端连接到ProxySQL执行查询时,ProxySQL会先根据预先设定好的路由规则进行路由检查,并分发到这条语句应该被执行的实例上。最简单的例子就是将所有的读查询全部路由到从库,所有的写查询全部路由到主库。当然,由于读查询有可能在从库上读到非最新的数据,这个案例在生产上并不是实用的,因此,我们建议将所有的请求都发到主库上,同时由于ProxySQL对SQL统计信息的支持,DBA可以针对性的创建更加精准的路由规则,将特定的查询路由到从库。详细信息和其他案例可以参考之前的文章
在ProxySQL支持高客制化的路由规则设定,甚至可以通过<代码> next_query_flagIN>
,上下文一致性读
虽然某些应用对数据实时性要求极高,但其对上下文一致性读还是兼容的,即客户端可以读到同一个ProxySQL连接中被自己修改后的数据。这个特性在MySQL默认的异步复制结构是无法保证的,异步复制情况下,在主上提交写后,从库上有可能因为传输时间占用或者执行速度的差异导致客户端并不能同时读到刚刚修改的最新数据。
那么我们如何保证只有当写事件被完全同步到从库后,查询才会由ProxySQL路由到从库呢?
基于GTID
GTID帮助。
在MySQL 5.7.5更新后,客户端可以知道其最后写入事务的GTID,而且可以在任何当前GTID代表的事务已经被执行的从库上进行读操作.Lefred在博客中举例描述了这个过程,如下:MySQL实例服务端开启session_track_gtids参数(这是个覆盖全局和线程级的参数,用于返回当前事务成功执行的标记和GTID编号)后,客户端就可以在从库上使用<代码>选择WAIT_FOR_EXECUTED_GTID_SET (& # 39; 3 e11fa47 - 71 - ca - 11 - e1 - 9 - e33 c80aa9429562:1 - 5 & # 39;) 的函数来判断刚刚在主库执行的写事务是否在从库上已经被执行。
虽然可以通过这种操作来保证上下文一致性读,但由于以下原因,这个方法对生产环境来说还是比较麻烦和不实用的:
在从库上执行业务查询时每次都要加上WAIT_FOR_EXECUTED_GTID_SET的话,会增加单个查询的响应时间
出于效率,若想从若干个从实例中找到已经执行完指定GTID的实例,可能需要在所有的从库上都执行一遍
很可能所有的从库在可接受的延迟等待时间内都没有完成该GTID的同步
也就是说上述的操作在生产环境中并不实用
,可以追踪GTID吗?
由于ProxySQL饰演着MySQL客户端的角色，当session_track_gtids 开启后，ProxySQL 也可以跟踪所有前端发来的所有请求的GTID，而且可以准确的获知每个前端连接最后的GTID值。这样就可以使用这些信息去路由读请求到正确的从实例（指已经执行完某个线程指定的GTID事务的从实例）上。那么，ProxySQL 怎么追踪指定的GTID是否在从库上已经被执行呢？
大概分为两种办法：
主动问询：ProxySQL 定期的查询所有实例的GTID执行情况
聆听告知，每当一个新的写事件产生且GTID编号被生成后，ProxySQL 会立刻接到告知
需要注意的是，由于每次问询之间总是有一定的间隔，导致主动问询方式总是不可避免的存在着基于问询间隔的延迟，问询的越频繁，获取的信息就越准确，但会增加MySQL实例的负载，且当ProxySQL实例过多时会占用查询带宽和流量。总而言之，理论上来说，这种办法效率又低，架构可扩展性又差。
那么聆听告知的情况
实时获取已经执行过的GTID值
从技术上来说获取当前已经执行过的GTID 值很简单，只要实时消费（分析）binlog即可。但是这种方法需要把ProxySQL实例所在的机器模拟成一个从库，如若单个ProxySQL负载了很多个MySQL实例，那么势必会对提升CPU的消耗。更进一步，如果一个机柜或者交换机上部署了很多ProxySQL 实例，那么传输binlog也会对整个网络的带宽带来考验。举个例子，现有4个集群，每个集群中的主库每天产生40GB的binlog并且挂了5个从库，附加30个ProxySQL实例，那么，每个ProxySQL实例需要把自己模拟成24个主从实例的从库。总计每天要消耗30TB的网络带宽。对自建机房的话或许可以直接纵向或者横向加硬件解决，但对云主机来说，每天将会无法避免巨额的流量费用。
