第 13 章 MySQL的复制

数据库的复制技术是提高数据库系统并发性、安全性和容错性的重要技术，是构建大型、高性能应用程序的基础。通过复制可以将数据存储在一个分布式的网络环境中，由多个数据库系统来提供数据访问服务，可以提高数据库的响应速度和并发能力。

13.1 认识MySQL复制

复制是从一个MySQL服务器将数据拷贝到另一台或多台MySQL服务器的过程。

13.1.1 复制的概念

MySQL复制是指将主数据库的DDL和DML操作通过二进制日志传到复制服务器上，然后在复制服务器上将这些日志文件重新执行，从而使复制服务器和主服务器的数据保持同步。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器、从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
在MySQL中，复制操作是异步进行的，即在进行复制时，所有对复制中的表的更新必须在主服务器上进行。从服务器不需要持续地保持连接来接受主服务器的数据，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。
MySQL支持一台服务器同时向多台从服务器进行复制操作，从服务器同时可以作为其他从服务器的主服务器，如果MySQL主服务器的访问量比较大，通过复制技术，从服务器来响应用户的查询操作，从而降低主服务器的访问压力，同时从服务器可以作为主服务器的备份服务器。
一般而言，数据库复制技术从以下3个方面改善分布式数据库集群系统的功能和性能：

1. 可用性：数据库集群系统具有多个数据库节点，在单个或多个节点出现故障的情况下，其他正常节点可以继续提供服务。
2. 性能：多个节点一般可以并行处理请求，从而避免单节点的性能瓶颈，一般至少可以提高读操作的并发性能。
3. 可扩展性：单个数据库节点的处理毕竟有限，增加节点数量可以显著提高整个集群系统的吞吐率。

13.1.2 复制的用途

由单台MySQL作为独立的数据库是完全不能满足实际需求的。因此，一般来说都是需要通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力，或者是用来作为主备机的设计，保证当主机停止响应之后在很短的时间内就可以将应用切换到备机上继续运行。
通过复制可以带来以下几个方便的优势：

• 数据库集群系统具有多个数据库节点，在单个或多个节点出现故障的情况下，其他正常节点可以继续提供服务；
• 如果主服务器上出现了问题可以切换到从服务器上；
• 通过复制可以在从服务器上进行查询操作，降低主服务器的访问压力，实现数据分布和负载平衡；
• 可以在从服务器上进行备份，以避免备份期间影响主服务器的服务。

13.1.3 复制的实现

MySQL的复制技术主要有 3 种：

1. DRBD是一种用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。
2. MySQL Cluter（MySQL簇）。MySQL Replication（复制）本身是一个比较简单的架构，即一台从服务器（Slave）从另一台主服务器（Master）读取二进制日志然后再解析并应用到自身。
3. 一个最简单复制环境只需要两台运行有MySQL的主机即可，甚至可以在同一台物理服务器主机上面启动两个MySQL实例。一个作为Master，另一个作为Slave来完成复制环境的搭建。但是在实际应用环境中，可以根据实际的业务需求利用MySQL复制的功能自己定制搭建出其他多种更利于扩展的复制架构，如最常用的主从架构。
   主从架构指的是利用一台MySQL服务器作为Master，一台或多台MySQL服务器作为Slave，将Master的数据复制到Slave上。在实际的应用场合中，主从架构模式是MySQL复制最常用的。一般在这种架构下，系统的写操作都在Master中进行，而读操作则分散到各个Slave中进行，因此这种架构特别适合解决目前互联网高度写比的问题。
   MySQL数据库复制操作大概分为以下几个步骤：
4. Master启用二进制日志。启用二进制日志的操作在日志管理中有详细介绍。
5. Slave上面的IO进程连接上Master，并且请求从指定日志文件的指定位置（或从最开始的日志）之后的日志内容。
6. Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。
7. Slave的IO进程接受到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中。
8. Slave的SQL检测到relay-log中新增加的内容后，会马上解析relay-log的内容，并在自身执行。

13.14 MySQL复制的几种模式

从MySQL 5.1.12开始，可以用以下3中模式来说实现：

• 基于SQL语句的复制（Statement-Based Replication，SBR）
• 基于行的复制（Row-Based Replication，RBR）
• 混合模式复制（Mixed-Based Replication，MBR）
  相应的，binlog的格式也有 3 种：STATEMENT 、ROW、MIXED。MBR模式中，SBR模式是默认的。在运行时可以动态的改变binlog的格式。设定主从复制模式的方法非常简单，只要在以前设定复制配置的基础上，再加一个参数，具体如下：
  binlog_format=‘STATEMENT’
  #binlog_format=“ROW”
  #binlog_format=“MIXED”
  当然了，也可以在运行时动态修改binlog的格式，
  SET SESSION binlog_format=‘STATEMENT’；
  SET SESSION binlog_format=‘ROW’；
  SET SESSION binlog_format=‘MIXED’；
  SET GLOBAL binlog_format=‘STATEMENT’；
  SET GLOBAL binlog_format=‘ROW’；
  SET GLOBAL binlog_format=‘MIXED’；

13.2 控制主服务器的操作

暂时不研究

13.3 控制从服务器的操作

暂时不研究（硬件达不到要求）

13.4 高手点拨

MySQL复制采用BINLOG进行网络传输，所以网络延迟是产生MySQL主从不同步的主要原因，通常会给程序进行读写分离带来一定的困难。为了避免这种请款，在配置服务器配置文件的时候最好使用InnoDB存储引擎的表，在主机上可以开启sync_binlog。
如果主机上的max_allowed_packet比较大，但是从机上确没有手工配置该值，默认为1MB，此时很有可能导致同步失败，建议主从两台机器上都设置为5MB比较合适。
另外从数据库无法同步的问题，如 show slave status 显示“Slave_SQL_Running为NO，Seconds_Behind_Master”为NULL。原因：程序可能在从机上进行了写操作，也可能是从机机器重启后，事务回滚造成的。
解决方法一：
slave stop；
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1；
slave start；
解决方法二：
slave stop；——停掉Slave服务