MYSQL主从同步

1、复制概述

Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。

1.1 mysql支持的复制类型：

（１）基于语句的复制： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。
一旦发现没法精确复制时， 会自动选着基于行的复制。
（２）基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
（３）混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

1.2 . 复制解决的问题

MySQL复制技术有以下一些特点：
(1) 数据分布 (Data distribution )
(2) 负载平衡(load balancing)
(3) 备份(Backups)
(4) 高可用性和容错性（High availability and failover）

1.3 复制如何工作

整体上来说，复制有3个步骤：

(1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
(2) slave将master的binary log events拷贝到它的中继日志(relay log)；
(3) slave重做中继日志中的事件，将改变反映它自己的数据。

下图描述了复制的过程：

image.png

1、该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。
2、下一步就是slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
3、 SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

2、配置

有两台MySQL数据库服务器Master和slave，Master为主服务器，slave为从服务器，初始状态时，Master和slave中的数据信息相同，当Master中的数据发生变化时，slave也跟着发生相应的变化，使得master和slave的数据信息同步，达到备份的目的。
要点：
负责在主、从服务器传输各种修改动作的媒介是主服务器的二进制变更日志，这个日志记载着需要传输给从服务器的各种修改动作。因此，主服务器必须激活二进制日志功能。从服务器必须具备足以让它连接主服务器并请求主服务器把二进制变更日志传输给它的权限。

根据上一篇文章我们已经在一台电脑上面配置了两个MYSQL服务了。这边我取3307端口的MYSQL作为主库，3308端口的MYSQL作为从库。

2.1、在主库创建一个slave用户并赋予REPLICATION SLAVE权限
命令 GRANT REPLICATION SLAVE ON . to 'slave'@'%' identified by '123456'
2.2、在配置之前保持主从库的数据一致。
2.3、配置master
在主库的MY.INI的MYSQLD节点下加入如下配置，然后重启服务
server-id=1
log-bin=master-bin
log-bin-index=master-bin.index
重启后输入SHOW MASTER STATUS查询得出二进制文件以及当前的位置，在下面配置slave的时候需要用到

image.png

2.4、配置slave
在从库的MY.INI的MYSQLD节点下加入如下配置，然后重启服务
server-id=2
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
注意server-id主从必须不同
2.5、启动slave
change master to master_host='127.0.0.1',
master_port=3307,
master_user='slave',
master_password='123456',
master_log_file='master-bin.000001',
master_log_pos=2410
这边的master_log_file和master_log_pos就是上面查询出来的结果
这段命令能够在不重启服务的情况下动态的改变主库配置

然后启动START SLAVE
在使用SHOW SLAVE STATUS查看主从连接状态

image.png

注意此处的Slave_IO_Running和Slave_SQL_Running的状态，Yes表示主从库连接成功，No的话可以查询err日志。

我遇到一个问题就是输出错误日志 slave have equal MySQL Server UUIDs，表明我的主从库拥有相同的UUIDs
在启动MYSQL服务的时候在data目录下会自动生成一个auto.cnf文件来生成一个UUID，可能是因为我的MYSQL 5.7 SERVER 3308文件夹是复制3307文件夹的方式过来的所以导致生成的同样的UUID。
解决办法就是随便删除一个服务的auto.cnf，然后重启服务让他重新生成一次就好了。

image.png

接下来就可以去测试是否真正实现了主从同步，测试后发现确实没问题了。

总结

1、配置主从同步主要是为了实现数据库的读写分离，写操作全部在主库，读操作在从库，这样能够大大缓解单个数据库的读写压力。
2、另外我们知道通常一个网站都是80%读与20%写，因此我们可以设置多个从库，将读的压力再次分配到多个服务器上，提高网站的读取性能。这边就涉及了复制的常用拓扑结构
复制的体系结构有以下一些基本原则：
(1) 每个slave只能有一个master；
(2) 每个slave只能有一个唯一的服务器ID；
(3) 每个master可以有很多slave；
(4) 如果你设置log_slave_updates，slave可以是其它slave的master，从而扩散master的更新。

拓扑结构参考一下http://blog.csdn.net/hguisu/article/details/7325124

3、这边要区分一下集群和主从的概念和作用
集群的话是分布式节点架构的存储方案，以便于提供容错性和高性能，在一个节点崩溃之后能够立即用另外一个节点代替。
而主从同步并达不到上面的效果，在主节点崩溃以后整个数据库就崩了。
因此真正高可用的MYSQL还需要两者的结合。