mysql 从业务角度解决读写分离的同步问题

1年前 ⋅ 48 阅读

严格意义上讲,MySQL 读、写分离确实存在上述情况,这是由Master-Slave 异步复制存在延迟所导致的,且Master binlog的写入为多线程,而Slave同步的sql_thread为单线程(MySQL5.6之前),两者写入速度不一致,在高并发写入的情况下,Slave节点延迟会更大;

所以,读、写分离时,一般的做法是,前端程序加判断,首先检查SLAVE节点同步位置以及状态是否同步至最新,确认其正常后,然后将查询请求发送至此节点。
方法如下:
1、请求发送过来时,首先在Master节点执行show master status,记录下当前的binlog以及position
2、在SLAVE节点上,执行 select master_pos_wait(binlog, pos[, timeout]) 等待同步到最新节点,然后发送查询请求,循环检测SLAVE节点上的执行位置,若未到P,则过几秒再查。循环直到从库追上。

 

函数master_pos_wait

    语法 select master_pos_wait(file, pos[, timeout]).
    这里的file和pos对应主库show master status得到的值,代表执行位置。 函数逻辑是等待当前从库达到这个位置后返回, 返回期间执行的事务个数。
    参数timeout可选,若缺省则无限等待,timeout<=0时与缺省的逻辑相同。若为正数,则等待这么多秒,超时函数返回-1.
    其他返回值:若当前slave为启动或在等待期间被终止,返回NULL; 若指定的值已经在之前达到,返回0

 

master_pos_wait的实现逻辑

    用户调用该函数后,根据传入参数调用pthread_cond_timedwait或pthread_cond_wait。 SQL_THREAD线程每次apply完一个事件后会触发更新relay info, 并通知上面等待的线程。因为可能有多个用户等待,因此用广播方式。

 

 

小结

用master_pos_wait来实现上面的步骤b,则可以简化为:
b’) 在M上执行select master_pos_wait(file, pos),返回后判断一下返回值>=0 则认为主从同步完成。

 

 好处是
1) 简化逻辑,不用在应用脚本判断
2) 在追上的第一时间就能感知,否则可能多等若干秒

 


全部评论: 0

    我有话说: