在寻求数据库安全以及数据库稳定性的时候，拥有一个Replication(副本)是非常重要的，在Mysql中我们可以使用设置主、从服务器的方式来达到这个效果。使用Replication的优点有很多，如：

1.实现数据库的负载均衡。比如可以由从服务器完成读任务，而主服务器进行写的任务，来达到减轻主服务器压力、提高读取效率的作用

2.备份功能。作为主库Replication的从库是一个非常好的备份，如果设置了延时同步的话，比如一个小时的同步延时，这样出现严重问题的时候，我们就可以有一个小时的时间发现它，并且使用从服务器未被污染的数据进行恢复。

3.实现高可用性和故障转移的功能。如在主数据库以外驻机的情况下，可以通过将从库提升为主库来达到迅速恢复，减少实际系统的驻机时间的效果。

Mysql主从同步的原理(Master – Slave)

而设置Replication的过程中，最重要需要解决的问题就是主从同步问题，也就是保持从库与主库的数据的一致性的问题。在Mysql中，支持两种主从同步Replication方法：

1.    基于语句的复制：数据库记录在主库上的操作语句，然后将语句在从库上重新执行(当然，不能单纯SQL命令，还有一些附带信息，如当前的时间戳等等需要被记录)。优点是记录文件体积小，缺点是主库上的查询操作也会被从库重新执行。

2.    基于数据行复制：Mysql5.1之后才支持的方式，通过记录实际的数据改动，记录被修改的行和修改的内容，在从库上对这些行进行修改。优点是复制数据高效，不必执行不必要的命令操作，缺点是记录文件会变得比较大，给传输带来压力。

这两种方式都是通过记录主服务器的二进制日志(上述提到的记录文件,Binary Log)，并将主服务器上的二进制文件拷贝到从服务器上，由从服务器进行回放(Replay)来完成复制过程，他们都是异步的。

由上所知：二进制日志里存放着命令、或者是数据行的同步数据，而主从同步的核心在于二进制文件的操作，而想要进行主从同步的主服务器一定要开启二进制日志才可以。

 

Replication 的大体工作流程如下：

1.       主服务器把数据更改记录到二进制日志(Binary Log)中。

2.       从服务器把主服务器的二进制日志拷贝到自己的Relay Log中.

3.       从服务器重放Relay Log 中的事件，将更改应用的自己的数据集中。

 

实际工作的示意图如下：

 

由上图可知，从服务器在进行Binary Log的读取时会开启一个I/O Slave 线程来进行读取，而自身的Replay则由一个SQL线程来执行，图上没有标明的时，在主服务器上也会启动一个线程，是有从服务器打开的连接在主服务器上启动的线程。

配置Mysql Replication

         创建Mysql Replication的过程大概有这几步:

1.       在主、从服务器上配置用于Replication的账号

2.       配置主、从服务器

3.       指导从服务器进行与主服务器的连接与复制

下面一一介绍这几步的具体过程。

 

1.配置Replication账号

由于从服务器要启动一个I/O进程来对主服务器的Binary Log进行读取，所以我们需要在主服务器上建立一个Replication账号，供从服务器的I/O进程使用，以此来登录主服务器，并读取Binary Log。

创建Replication账号的命令：

GRANT REPLICATION SLAVE ,REPLICATION CLIENT ON *.*  TO repl@’192.168.0.%’ IDENTIFIED BY ‘p4ssword’

此命令在主从服务器上都创建了一个名为repl的用户，它被限定成一个在局域网内的用户，其中REPLICAION　SLAVE和REPLICATION CLIENT是两个权限。其中：

REPLICATION CLIENT是进行Replication所需要的基本权限，而

REPLICATION SLAVE是对Replication进行监视和管理所需要的权限，此权限可以不grant。

2.配置主、从服务器

所有的服务器不论主从必须分配一个唯一的Server ID，用来分辨每个服务器

 

Master Server 配置：(在my.cnf中修改)

log_bin =mysql-bin   #指定Binary Log的名称

server_id=1         #指定Server id

sync_binlog=1       #让Mysql在每次提交事务的时候把Binary Log同步到磁盘上

 

检查：

可用SHOW MASTER STATUS命令来进行查看，内容应该为.

l  其中指出了Binary Log的实际名字

l  Position比较重要，是当前Binary Log的所处位置。

 

Slave Server配置：

log-bin =mysql-bin

server_id =2

relay_log =mysql-relay-login

log_slave_updates=1

read_only=1

其中

l  log-bin和relay-log指定了本机Binary Log和Relay Log的文件名

l  log_slave_updates指出从服务器把Replication的事件也记录在本机的Binary Log中，这样可以实现多级的Master Slave结构（从服务器也可以做其他服务器的主服务器）

l  read_only指明没有特殊权限的线程不可以修改数据，用于一般Slave只作为读取的情况下用

3.启动Replication

         (在启动Slave之前，要清楚，必须在Slave数据库中先导入相关的表结构，否则不管支持行式或命令式的Binary Log都会报错。)

         指出从服务器如何连接到主服务器并找到其Binary Log.主要使用的命令为CHANGE MASTER TO命令，此命令在SLAVE的客户端执行。

         命令一般为：

CHANGE MASTER TO MASTER_HOST=’server1’, MASTER_PORT=’1234’ MASTER_USER=’repl’,MASTER_PASSWORD=’p4ssword’,MASTER_LOG_FILE=’mysql-bin.000003’,MASTER_LOG_POS=0;

l  MASTER_HOST指出MASTER的主机名

l  MASTER_PORT指出MASTER服务的端口。

l  MASTER_USER 给定之前我们用GRANT命令添加的用户名

l  MASTER_PASSWORD给定密码

l  MASTER_LOG_FILE给出主机上的Binary Log实际文件名(注意后面的数字号,由MASTER 执行SHOW MASTER STATUS命令所得)

l  MASTER_LOG_POS给出开始执行的行数在MASTER Binary Log中的位置，也应该由SHOW MASTER STATUS命令而得。0表示开头。

 

检查：

使用SHOW SLAVE STATUS命令检查slave 状态

要注意Slave_IO_Running,Slave_SQL_Running, Slave_IO_State等状态，它们给出了从服务器进程的运行情况，如果运行了Slave Start之后，这三个状态还是如上图，则说明可能你的配置出错了。

 

执行Start Slave命令，启动从服务器，查看状态应该如下：

检查Slave相关状态，发现状态正常，线程正常，则说明连接成功。

(PS:如果start之后发现Slave_IO_Running还未No则需要检查是否是账户问题，或者在master上执行flush logs强制其使用新的日志，重新设置，看是否有问题)

另外也可以使用SHOW PROCESSLIST命令，来查看服务器的线程情况。至此，配置完成，从服务器可以使用LOAD DATA FROM MASTER 语句来获取主服务器上的数据了(会锁主服务器的表，进行传输，且只能用于MyISAM)

至此，简单的Mysql Replication就完成了，进阶请看《高性能Mysql》，书很经典，翻译很烂。

另附Binary Log的可能格式：每行依次为 偏移量，发生时间、服务器Id、结束偏移等等，时间戳，命令/数据?