主数据库的增删改等操作记录到二进制日志文件中,从库接收主库日志文件,根据日志最后一次更新的起始位置,复制到从数据库中,使得主从数据库保持一致。
主从复制又有异步复制和半同步复制。
Binary Log:主数据库的二进制日志;
Relay Log:从服务器的中继日志。
复制过程:
(1)主库在每次事务完成前,将该操作记录到binlog日志文件中;
(2)从数据库中I/O线程负责连接主库服务,并读取binlog日志变化,如果发现有新的变动,则将变动写入到relay-log,否则进入休眠状态;
(3)从库中的SQL Thread读取中继日志,并串行执行SQL事件,使得从库与主库始终保持一致。
注意事项:
(1)涉及时间函数时,会出现数据不一致。原因是,复制过程的两次IO操作和网络、磁盘效率等问题势必导致时间戳不一致;
(2)涉及系统函数时,会出现不一致。如:@@hostname,获取主机名称,主从数据库服务器名称不一致导致数据不一致;
4.异步复制
master事务的提交不需要经过slave的确认,slave是否接收到master的binlog,master并不去关心。slave接收到master binlog后先写relay log,最后异步地去执行relay log中的SQL应用到自身。由于master的提交不需要确保slave relay log是否被正确接受,当slave接受master binlog失败或relay log应用失败,master无法感知。
假设master发生宕机并且binlog还没来得及被slave接收,而切换程序将slave提升为新的master,就会出现数据不一致的情况!另外,在高并发的情况下,传统的主从复制,从节点可能会与主产生较大的延迟(当然MySQL后续版本陆续做了优化,推出了并行复制,以此降低异步复制的延迟)
5.半同步复制
基于传统异步存在的缺陷,MySQL在5.5版本推出半同步复制。可以说半同步复制是传统异步复制的改进,在master事务的commit之前,必须确保一个slave收到relay log并且响应给master以后,才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的,原理如下图所示: