1.复制的原理
复制大概可分为三个步骤:
- 数据修改写入master数据库的binlog中。
- slave的IO线程复制这些变动的binlog到自己的relay log中。
- slave的SQL线程读取并重新应用relay log到自己的数据库上,让其和master数据库保持一致。
复制是基于binlog的position进行的,复制之前必须保证position一致。
2.复制的优点
- 提供了读写分离的能力;
- 为MySQL服务器提供了良好的伸缩(scale-out)能力;
- 数据库备份时,对业务影响降到最低;
- 能提升数据的安全性;
- 数据分析不再影响业务。
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
从库查看是否复制: