MySQL之Replication

MySQL复制是MySQL提供的一个重要功能，通过它可以将一个MySQL Server的Instance中的数据完整复制到另一个MySQL server 的Instance中。虽然复制过程并不是实时而是异步进行的，但是由于良好的设计，延迟比较小。该功能在实际应用中，常用来保证系统数据的安全性和系统的可扩展性。
通过MySQL复制，可以将一台MySQL服务器上的数据完整且“同时”复制奥另一台MySQL服务器中，正常情况下，复制的延时并不高。等各台服务器同步了数据之后，对数据的读取就可以通过对不同服务器的访问来实现。

---

一、Replication实现原理
首先要指出的是，MySQL的Replication是一个异步复制的过程。被复制的原MySQL instance称为Master，目标MySQL instance称为Slave。一个最简单的复制架构由一个Master和一个Slave组成，其中涉及到三个线程，分别是位于Master的IO线程和位于Slave的IO线程以及SQL线程。
要实现Replication过程，必须做一些准备工作。首先是要打开Master的Binary Log功能，二进制日志记录了对数据库执行更改的所有操作，但是不包括select和show这类操作，因为这类操作并没有对数据库进行修改。二进制日志在默认情况下是未开启的，所以需要手动打开。根据《MySQL技术内幕-InnoDB存储引擎》中关于该功能的介绍，以及官方手册中的测试表明，开启二进制日志会使性能有1%的下降。但是考虑到通过二进制日志可以实现Replication功能，这一点性能损失完全可以接受。
从MySQL5.1开始，可以设置binlog_format参数，该参数二进制日志记录的形式。有三个可选项：STATEMENT ROW MIXED。（1）STATEMENT，此时二进制日志记录的是逻辑SQL语句。（2）ROW，此时二进制日志则记录了对表的行更新情况。（3）MIXED，在该模式下，MySQL会根据执行的sql语句来选择一种合适的二进制日志记录形式。
当打开Master的二进制日志功能之后，复制才能使用。整个复制过程就是Slave通过获取Master的二进制日志，然后在本地重做所有操作，来达到与Master端的同步。
整体大致的复制过程如下：
（1）Slave的IO线程连接上Master，并请求日志文件的指定位置之后的日志内容；
（2）Master接收到来自Slave的请求后，负责复制的IO线程根据上述请求的日志位置，读取日志信息，并返回给Slave的IO线程。返回的信息除了包括日志信息外，还包括本次返回的信息在Master中二进制日志的名称和位置。
（3）Slave端的IO线程接收到来自Master的信息，将日志内容写入到Slave端的Relay Log文件的最末端，并记录下Master端的二进制日志名称和位置记录到mater-info文件中，以便在下一次向master请求时携带信息。
（4）Slave端的SQL线程检测到Relay Log文件中有新内容后，会马上将其中的内容转换为可执行的SQL语句，并执行这些语句。

二、Replication常用架构
（1）Master-Slaves
这是在日常用的最普遍的复制架构，一个Master可以连接多台Slave。在Master端并不在乎有多少个Slaves连接了自己，只要有Slave的IO线程通过了连接认证，向它请求指定位置之后的Binary Log信息，它就会按照该IO线程的要求，读取自己的Binary Log并返回给此IO线程。只要Master和Slaves的压力不是太大（尤其是Slave），异步复制的延时一般都很小。通过这样的架构，就可以将Master上过大的读取压力分散到Slaves上。
（2）Master-Master
这种架构是为了满足在某些场合下的Master切换，如Master维护或者Master发生故障。通过搭建Dual Master环境，可以让两个MySQL server互相将对方视为自己的Master，自己作为Slave来复制。这样，任何一方所做的更改，都会通过复制应用到另外一方的数据库中。
（3）Master-Slaves-Slaves
当一个Master下连接的Slaves特别多时，Master也会有比较大的压力，此时，可以通过多级Slaves连接，达到分散Master端压力的目的。首先通过少数被称为第一级的几台Slaves从Master进行复制，然后其他Slaves再从第一级来进行复制，理论上可以往下增加更多的层次。
（4）Master-Master-Slaves
第三种方式在一定程度上解决了Master因为连接Slaves过多而造成的瓶颈问题，但是仍然不能解决人工维护和出现异常需要切换时可能存在的重新搭建Replication的问题。由此产生了第四种架构Master-Master-Slaves。与第三种架构不同的是，将第一级的Slaves换成了Master，作为备用Master，然后再从备用Master复制到一个Slaves集群。但是这种架构备用Master容易成为瓶颈。

三、Replication搭建