Mysql主从集群可以保证从节点和主节点数据一致,这个是通过基于Binary Log的主从复制异步实现的。
复制原理
复制过程
- 主节点将自己所有的写操作记录在自己的Binary Log中,主节点维护一个IO线程
- 从节点维护一个IO线程,定期向主节点查询是否有新的写操作,如果有,那么主节点通过IO线程把新的写操作发送给从节点。
- 从节点将得到的写操作记录写入到自己的Relay Log中。
- 从节点维护一个SQL线程,将Relay Log中的SQL操作都写入到数据库。
从复制过程可以看出,从节点上的IO线程和SQL线程只是共享Relay Log,其余部分互不影响,所以就是异步的;IO线程把Binary Log拿过来,SQL线程可能过一会儿再去执行它。
因此,从节点需要知道两个文件名和两个位置:一个是主节点上Binary Log的文件名和IO线程读取的Binary Log的最新位置,每次查询的时候通过位置判断是否有新的写操作,用show slave status\G;
查询,Master_Log_File
和Read_Master_Log_Pos
分别表示Binary Log的文件名和位置;另一个是自己Relay Log的文件名和SQL线程执行到的位置,用show slave status\G;
查询是Relay_Log_File
和Exec_Master_Log_Pos
.
当从节点出现数据库不一致的情况时,一般会出现Exec_Master_Log_Pos
小于Read_Master_Log_Pos
的情况,因为SQL线程执行语句出错了,那么就会停止执行之后的语句。这个时候Exec_Master_Log_Pos
就能排上用场了,因为它表示的是最后一个正确操作的位置,那么我们只要能手动解决出错的东西(比如说可能是主节点上的某个操作在从节点上存在逐渐冲突,那么删了那条冲突的记录就好了),然后重新启动slave,从Exec_Master_Log_Pos
开始重新同步就可以了。详细操作步骤可以参考另一篇博客Mysql 主从节点不同步的解决方法