Mysql主从架构的复制原理及配置详解

作者:bruce2088  发布日期:2013-12-10 09:49:31
一、什么叫mysql复制?

   关于mysql复制,我是这样理解的:将某一台主机上的Mysql数据复制到其它主机(slaves)上,并重新执行一遍从而实现当前主机上的mysql数据与(master)主机上数据保持一致的过程我们可以称为复制。

   复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。

 

二、mysql复制是如何工作的?
 


 

   从上图看mysql的主从复制整体来说分为3个部分:

   1、master将状态信息的改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);

   2、slave将master的binary log events拷贝到它的中继日志(relay log);

   3、slave重做中继日志中的事件,将状态信息的改变存储到本地磁盘行成数据;

 

   详细描述如下:

   首先该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前,master在二日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后,master通知存储引擎提交事务。

   接下来就是slave将master的binary log拷贝到它自己的中继日志。先是slave开始一个工作线程——I/O线程,I/O线程在master上打开一个普通的连接,然后开始binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件(Seconds_Behind_Masterk可以观察落后的状态),I/O线程将这些事件写入中继日志。

   最后SQL thread(SQL从线程)从中继日志读取事件,并执行事件语句更新slave的数据,使其与master中的数据一致。

 

   此外,在master中也有一个工作线程:和其它MySQL的连接一样,slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的,也就是说master上的并行更新操作不能在slave上并行操作(slave会有数据上的延时)。

 

三、复制能解决的问题及mysql支持的复制类型:

   1、MySQL复制技术有以下一些好处:

       1.1、数据分布 (Data distribution )

       1.2、可以实现负载均衡(load balancing),通常所说的读写分离

       1.3、可以实现数据的备份(Backups),但是不能当真正意义上数据备份来用

       1.4、高可用性和容错行(比如双主模型中的互为主从能实现高可用)

   2、复制类型:

       2.1、基于语句的复制(statement):在主服务器上执行的SQL语句,在从服务器上执行同样的语句。

            优点:基于语句的复制,效率比较高;需要注意地方:可能无法精确复制,比如sql中更新时间的时候如果不是精准值而是time();什么的,由于主从复制有延时导致数据的不一致。

       2.2、基于行的复制(row):把改变的内容复制过去,而不是把命令在从服务器上执行一遍。数据复制相对安全,但是产生的日志文件会过大,比如update某一范围来数据的状态,这个范围有1W条数据,就会产生1W条update语句;

       2.3、混合类型的复制(mixed): mysql5.5默认采用混合类型的复制,也就是上面的两种根据情况变换着复制。此方法可能会打乱日志的结构,一会基于语句一会儿基于行,日志排查日志的可能看起来不太好使;

   3、mysql复制中需要注意的问题:

       1、主从服务器mysql的版本,主库的版本可以低于从库,但是从库的版本一定不能低于主库(从版本 >= 主版本)

 

四、主从复制的配置:

 1、主从服务器各自需要的准备操作  

       1.1、主服务器:

           a、创建具有复制权限的用户帐号;

               mysql> grant replication slave, replication client on *.* to copyuser@'172.16.5.%' identified by '123456';

               mysql> flush privileges;

           b、设置server-id;

               # server-id = 10

           c、启用二进制日志;

               # log-bin = /mydata/log/mysql-bin        日志存放位置

               # binlog_format = row                    基于行复制

 

       1.2、从服务器:

           a、启用中继日志;(可选:关闭二进制日志)

               # relay-log = /mydata/log/relay-bin     日志存放位置

               # read-only = 1                         设置为只读(对root权限账号无效)

           b、设置server-id;

               # server-id = 20

           c、启动复制线程;

               # change master to master_host='172.16.5.100' master_user='copyuser' master_password='123456'

               # slave start;

               查看状态:

               # show slave status\G;

               # show processlist;

               在这里主要是看:

               Slave_IO_Running = Yes

               Slave_SQL_Running = Yes

               如果需要只复制某些库可以指定过滤条件;

               replicate-do-db        = db1,db2      只复制某库

               replicate-do-table     = db1.mytbl    只复制某库某表

               replicate_ignore_db    = db3          不复制某库

               replicate_ignore_table = db1.nytb3    不复制某库中的某表

 

五、深入了解复制

   1、一主多从

       由一个master和一个slave组成复制系统是最简单的情况。Slave之间并不相互通信,只能与master进行通信。在实际应用场景中,MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式,主要用于读压力比较大的应用的数据库端廉价扩展解决方案。

在上图中,如果一主拖了多个从的话,这时主库既要负责写又要负责为几个从库提供二进制日志,此时可以稍做调整,将二进制日志只给某一从,这一从再开启二进制日志并将自己的二进制日志再发给其它从,或者是干脆这个从不记录只负责将二进制日志转发给其它从,这样架构起来性能可能要好得多,而且数据之间的延时应该也稍微要好一些。

 

 

   2、主主复制

上图中,Master-Master复制的两台服务器,既是master,又是另一台服务器的slave。这样,任何一方所做的变更,都会通过复制应用到另外一方的数据库中。在这种复制架构中,各自上运行的不是同一db,比如左边的是db1,右边的是db2,db1的从在右边反之db2的从在左边,两者互为主从,再辅助一些监控的服务还可以实现一定程度上的高可以用。

 

 

   3、主动-被动模式(HA)

上图中,这是由master-master结构变化而来的,它避免了M-M的缺点,实际上,这是一种具有容错和高可用性的系统。它的不同点在于其中只有一个节点在提供读写服务,另外一个节点时刻准备着,当主节点一旦故障马上接替服务。比如通过corosync+pacemaker+drbd+mysql就可以提供这样一组高可用服务,主备模式下再跟着slave服务器,也可以实现读写分离。

   

   4、mysql-5.5支持半同步复制

       mysql复制我们都知道是基于异步来实现的,但是从mysql-5.5开始,支持半自动复制。在以前版本中异步(asynchronous)复制中,主库在执行完一些事务后,是不会管备库的进度的。如果备库处于落后,而更不幸的是主库此时又出现Crash(例如宕机),这时备库中的数据就是不完整的。简而言之,在主库发生故障的时候,我们无法使用备库来继续提供数据一致的服务了。Semisynchronous Replication(半同步复制)则一定程度上保证提交的事务已经传给了至少一个备库。Semi synchronous中,仅仅保证事务的已经传递到备库上,但是并不确保已经在备库上执行完成了。

       此外,还有一种情况会导致主备数据不一致。在某个session中,主库上提交一个事务后,会等待事务传递给至少一个备库,如果在这个等待过程中主库Crash,那么也可能备库和主库不一致,这是很致命的。如果主备网络故障或者备库挂了,主库在事务提交后等待10秒(rpl_semi_sync_master_timeout的默认值)后,就会继续。这时,主库就会变回原来的异步状态。

 

MySQL在加载并开启Semi-sync插件后,每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务,两台主机的延迟又较小,则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。
 

Tag标签: 主从架构  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规