MySQL复制的工作流程

复制的核心步骤

1. 在主库上把数据更改记录到二进制日志（Binary Log）中;
2. 备库将主库上的日志复制到自己的中继日志（Relay Log）中;

3. 备库读取中继日志中的事件，将其重放到备库数据之上;

   下图即MySQL复制如何工作的细节
   

第一步，在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。

第二步，备库首先会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储（binlog dump）线程，该线程会读取主库上二进制日志中的事件。它不会对事件进行轮询，只有它赶上主库时会进入睡眠状态，直到主库发送信号量，备库I/O线程会将接收到的事件记录到中继日志中。

第三步，备库的SQL线程从中继日志中读取事件并在备库执行，从而实现备库数据的更行。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所以中继日志的开销很低。

配置复制

假设主库和备库拥有相同的初态，同时由于MySQL的向后兼容性，备库的版本不能低于主库版本。此时有服务器server1（192.168.0.1）和服务器server2（192.168.0.2）。

1. 创建复制帐号

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.2' IDENTIFIED BY 'password';

在备库运行的I/O线程会建立一个到主库的TCP/IP连接，因此必须在主库创建一个用户并赋予合适的权限。
2. 配置主库和备库
假设主库是server1，在主库的my.ini或my.cnf文件中增加或修改以下内容：

log_bin = mysql-bin
# 注意每个服务器server_id应该互不相同
server_id = 1

必须明确指定一个唯一的服务器ID。如果之前没有在MySQL的配置文件中指定log-bin选项，就需要重新启动MySQL。通过下面命令确认二进制日志文件是否已经在主库上创建：

mysql> SHOW MASTER STATUS;

备库上也需要在my.ini或my.cnf中增加类似配置，并重启MySQL:

log_bin = mysql-bin
server_id = 2
# 指定中继日志的位置和命名
relay_log = /var/lib/mysql/mysql-relay-bin
# 允许备库将其重放的事件也记录到自身的二进制日志中
log_slave_updates = 1
read_only = 1

如果可能的话，最好使用read_only配置选项，该选项会阻止任何没有特权权限的线程修改数据。但read_only选项常常不是很实用，特别是对于那些需要在备库建表的应用。
3. 启动复制
接下来是告诉备库如何连接到主库并重放其二进制日志，我们使用CHANGE MASTER TO语句替代my.cnf中相应的设置：

mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.1',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='password',
    -> MASTER_LOG_FILE='mysql_bin.000001',
    -> MASTER_LOG_POS=0;

MASTER_LOG_FILE和MASTER_LOG_POS参数是主库中SHOW MASTER STATUS中显示的File和Position字段。两个参数必须保持与主库一致，这样才能保证读取二进制日志的位置相同。当执行完上述语句后，可以通过以下语句检查复制是否正确执行：

mysql> SHOW SLAVE STATUS\G

如果Slave_IO_State、Slave_IO_Running和Slave_SQL_Running显示当前备库复制未运行，则可能原因为：

1. 网络连接问题（如防火墙阻止3306端口）
2. 密码错误
3. 权限设置问题

发生错误时可以通过查看mysql错误日志分析具体原因。如果Slave_IO_Running和Slave_SQL_Running都显示Yes则表明此时server1->server2的单向复制已成功开启。

结论

现在大家可以尝试在server1上进行编辑、插入、删除数据等操作并查看server2上的数据，从而测试MySQL复制是否配置成功。
如果想实现server1<–>server2的双向复制，只要用同样的方法将server1设置为server2的从服务器即可。