复制解决的问题
MySQL的复制使用二进制文件通常不会对带宽造成很大的压力，复制可以使相同数据很方便的同步到不同的服务器上。
通过MySQL复制可以将°操作分布到不同的服务器上，实现对读密集型应用的优化，即达到负载均衡的目的。
数据库备份。
数据库防灾。
工作原理
在主库上把数据更改记录到二进制日志中。
从库将主库的日志复制到自己的中继日志中。
从库读取中继日志中的事件，将其重放到备库数据中。
MySQL的复制架构允许获取事件的I/O线程和重放事件的SQL线程异步进行。但是在主库上并发执行的查询在从库中只能串行化执行，因为只有一个SQL线程来重放中继日志事件。
配置方法
首先需要两个版本、扩展完全相同的数据库。(MySQL具有向下兼容性,高版本可以做低版本的备库，反之则不行。使用相同版本数据库可以避免很多麻烦)
创建复制账号
MySQL会赋予一些特殊的权限给复制线程。在从库运行的I/O线程会建立一个到主库的TCP/IP连接，因此需要创建一个具有响应权限的用户。从库I/O线程以该用户连接主库并获取二进制日志。
grant replication slave, replication client on *.* to repl@'120.%' identified by 'repl123456';
配置主从库
主库
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服务。
告诉从服务器如何连接到主服务器
`show slave status \G`
`Slave_IO_State`当前复制I/O线程状态
`Slave_IO_Running: No` I/O线程未启动
`Slave_SQL_Running: No` SQL重放线程未启动
启动复制
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不同，重启服务。
