MySQL第六天-读写分离

Posted 2021-05-02 21军机处

  在《第五天》里，主要介绍了双主复制的配置原理以及一种基于故障检测思路。双主切换有两种方式，即主动切换和被动切换，而被动切换则是主动出问题了切到备库上。此时客户端不仅要将流量切到被库，如果有从库的话还要将从库的master切到备库上，为了实现这种机制，我们引入了Keepalived通过VIP漂移的方式实现主备切换。

 在上一文的脚本的逻辑很简单，就是判断数据库是否出问题，如果是那么就将keepalived进程杀掉，此时VIP会漂移到备库上。可以看到我使用的方式是：如果能连上数据库，那么就认为数据库没问题。事实上，判断数据库是否正常还有其他更有效的办法。

如何判断数据库是否正常

       

  第一种：连接到数据库之后运行select 1；这也是很多HA软件默认的判断方法。但是如果因为死锁或者锁等待的情况出现时，从主观的情况来判断应该切换了，但是实际上因为select 1可以执行成功而没有切换。所以这种办法虽然很好用，但是只能判断库的进程还在，在一些特殊情况下不能判断库的问题。

第二种：通过update语句更新一个特殊的表，里面有意义的字段，一般可以是timestamp字段用来标识当时检测的时间。除了timestamp之外，还可以需要添加一列server_id做主键，如果这个表只有一行的话，同时检测主备库的话就可能出现问题。因为在双主架构下，备库的命令也会返回给主库，会导致行冲突造成主备同步停止。

  类似的检测命令类似：

insert into sumatest.check_stauts(id, check_time) values (@@server_id, now()) on duplicate key update check_time=now();

  第三种：利用performance_schema数据库来判断,这个库里记录了数据库的一些性能参数，本次暂不过多介绍

双主多从

  关于如何判断数据库是否正常，就先说到这。在《第五天》里，我们知道了一个典型的双主架构可能是这样的：

随着业务的不断发展，首先会需要的问题可能读的性能问题，因为传统的业务都是读多写少，所以慢慢的数据库架构就会变成一主多从，为了防止单点故障，发展成了一主多从，也就是这样：

        

读写分离的架构

   通过双主多从的结构我们可以知道，双M主备库之间利用keepalived进行VIP浮动切换，双M之前拉取binlog进行同步，对client只提供写服务；同时slave从master拉取binlog，对client只提供读服务。

        Clinet负载

  通过双主多从的图可以看出来，属于客户端直连方案，整体的结构比较简单，所有的工作都在client上进行配置，有些工作需要研发对接，在主备切换、系统扩容等场景对我们用服人员来说不是特别的友好。

       代理负载

 在client和数据库的server层加入代理proxy，所有的连接、负载等信息都是通过proxy来完成，所以网络结构就变成了这样：

        *DNS轮询

  这个办法是我脑洞大开想的，没实践过，结合上面两种办法理论上性能也比不上proxy的那种情况，算是开拓思路吧。

   在clinet层对读和写语句进行区分到不同的域名，然后通过dns轮询进行负载到不同的服务器上。

      

   但是无论选择哪种方案，在主主复制或者主从复制都会存在主备延迟时间，即主库执行完一个事务写入binlog的时间T1到备库执行完成的时间T3的时间差，即T3-T1。

   由于主备延迟的出现，会造成当主库刚写入更新了几行信息之后，立即在slave上对这些信息进行查询，得到的结果很可能不一致，即过期读。那么主备延迟是如何出现的？如何避免过期读？见《mysql第七天-主备延迟》