MySQL的主从复制

复制解决的问题

1. MySQL的复制使用二进制文件通常不会对带宽造成很大的压力，复制可以使相同数据很方便的同步到不同的服务器上。

2. 通过MySQL复制可以将°操作分布到不同的服务器上，实现对读密集型应用的优化，即达到负载均衡的目的。

3. 数据库备份。

4. 数据库防灾。

工作原理

1. 在主库上把数据更改记录到二进制日志中。

2. 从库将主库的日志复制到自己的中继日志中。

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

MySQL的复制架构允许获取事件的I/O线程和重放事件的SQL线程异步进行。但是在主库上并发执行的查询在从库中只能串行化执行，因为只有一个SQL线程来重放中继日志事件。

配置方法

1. 首先需要两个版本、扩展完全相同的数据库。(MySQL具有向下兼容性,高版本可以做低版本的备库，反之则不行。使用相同版本数据库可以避免很多麻烦)

2. 创建复制账号
   MySQL会赋予一些特殊的权限给复制线程。在从库运行的I/O线程会建立一个到主库的TCP/IP连接，因此需要创建一个具有响应权限的用户。从库I/O线程以该用户连接主库并获取二进制日志。

grant replication slave, replication client on *.* to repl@'120.%' identified by 'repl123456';

1. 配置主从库

   • 主库

   • log_bin = mysql-bin#开启主库二进制日志

   server_id = 5581120 #主从拓扑唯一服务id,除非为了实现特殊拓扑结构，一般情况下，这个id必须是唯一的，不然容易造成循环复制等一系列麻烦
   配置完成后重启mysql服务，执行show master status。

- 从库
- 
`server_id = 268142`

`relay_log = /data/mysql/mysql-relay-bin #中继日志存储地址`
`read_only = 1 #从库设置为只读，非必须选项`

配置完成后重启mysql服务。

1. 告诉从服务器如何连接到主服务器
   

`show slave status \G`

`Slave_IO_State`当前复制I/O线程状态

`Slave_IO_Running: No` I/O线程未启动

`Slave_SQL_Running: No` SQL重放线程未启动

1. 启动复制start slave \G
   

测试同步结果

在主库创建一个数据库之后，从库立即同步了一个过来

开启过程中遇到的一些问题

error connecting to master 'repl@120.55.81.120:3306' - retry-time: 60 retries: 55 errno: 2003

确保服务器的防火墙不会阻止3306端口，确保repl用户可以通过从库ip访问主库。

---

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

mysql5.6的复制引入了uuid的概念，各个复制结构中的server——uuid得保证不同。找到data文件夹下的auto.cnf文件，修改里面的uuid值，保证每个db的uuid不同，重启服务。