Mysql高可用(二)主从复制

1.复制的原理

复制大概可分为三个步骤：

1. 数据修改写入master数据库的binlog中。
2. slave的IO线程复制这些变动的binlog到自己的relay log中。
3. slave的SQL线程读取并重新应用relay log到自己的数据库上，让其和master数据库保持一致。

复制是基于binlog的position进行的，复制之前必须保证position一致。

2.复制的优点

1. 提供了读写分离的能力；
2. 为MySQL服务器提供了良好的伸缩(scale-out)能力；
3. 数据库备份时，对业务影响降到最低；
4. 能提升数据的安全性；
5. 数据分析不再影响业务。

3.复制的实现

主数据库：172.25.60.20

备库：172.25.60.21

1.安装数据库：

2.修改密码：

在日志中找到默认密码：

进行修改：

3.修改配置文件以支持复制：

这是备库，主库也要修改：

4.在主库添加许可：

5.在备库添加主库提供的信息，并查看进程是否开启：

6.测试：在主库修改数据，备库查看是否同步：

主：

备：

4.基于GTID的主从复制

从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

GTID (Global Transaction ID)是全局事务ID,当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务，对DBA来说意义就很大了，我们可以适当的解放出来，不用手工去可以找偏移量的值了，而是通过CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1的即可方便的搭建从库，在故障修复中也可以采用MASTER_AUTO_POSITION=‘X’的方式。

GTID的工作原理：

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中；
2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中；
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录；
4、如果有记录，说明该GTID的事务已经执行，slave会忽略；
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog；
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

实现：

主库：172.25.60.20

备库：172.25.60.21

1.修改配置文件：

主库：

备库：

2.主库添加许可：

查看：

3.备库添加主库提供的信息：

查看进程是否开启：

4.测试：

主库新建database xixi

从库查看是否复制：