复制概述
复制解决的基本问题是让一台服务器的数据与其他服务器保持同步
MySQL支持两种复制方式:基于行的复制和基于语句的复制,通过在主库上记录二进制日志,然后在备库重放日志的方式来实现异步数据的复制
复制解决的问题
- 数据分布:比如在不同的地理位置存放数据备份,不同的数据中心
- 负载均衡:通过复制将读操作分布到多个服务器上,实现对读密集型应用的优化
- 备份:复制是备份的一种补充,代替不了备份
- 高可用性和故障切换:避免单点故障,切换备库缩短宕机时间
- MySQL升级测试
复制如何工作
- 在主库上把数据更改记录到二进制日志(Binary Log)中(这些记录被称为二进制日志事件)
- 备库将主库上的日志复制到自己的中继日志(Relay Log)中
- 备库读取中继日志中的事件,将其重放到备库数据之上
- 两个新的数据库之间的配置
创建复制账号、配置主库和备库、启动复制
- 从另一个服务器开始复制
一个已经运行了一段时间的主库,然后用一台新安装的备库与之同步,此时这台备库还没有数据,需要三个条件来让主库和备库保持同步:
- 在某个时间点的主库的数据快照
- 主库当前的二进制日志文件,二进制日志文件中的偏移量(日志文件坐标)
- 从快照时间到现在的二进制日志
- 从别的服务器克隆备库的方法
- 冷备份:关闭数据库,拷贝数据文件
- 热备份:mysqlhotcopy、rsync
- mysqldump
- 快照或备份
- Xtrabackup:可以在不影响主库的情况下设置备库
- 如果是从主库获得备份,可以从xtrabackup_binlog_pos_innodb文件中获得复制开始的位置
- 如果是从另外的备库获得备份,可以从xtrabackup_slave_info文件中获得复制开始的位置
复制的原理
- 基于语句的复制
主库会记录那些造成数据更改的查询,当备库读取并重放这些事件时,实际上只是把主库上执行过的sql再执行一遍
优点:
当主备的模式不同时,逻辑复制能够在多种情况下工作:比如数据类型不同、列的顺序不同;基于语句的复制方式一般允许更灵活的操作;基于预计的方式执行复制的过程基本上就是执行SQL语句。出现问题容易定位。
缺点:
对于储存过程、触发器,存在Bug;如果正在使用触发器或者储存过程,就不要使用基于语句的复制模式,除非能够清楚的确定不会碰到复制问题
- 基于行的复制
将实际数据记录在二进制日志中,可以证券的复制每一行数据
优点:
几乎没有基于行复制模式无法处理的场景,容易找到并解决数据不一致的情况;比如基于语句的复制模式,在备库更新一个不存在的记录时不会失败,但在基于行的复制模式下则会报错并停止复制
缺点:
由于语句并没有在日志里记录,因为无法判断执行了哪些SQL;使用一种完全不同的方式在备库进行数据变更,执行基于行的变化的过程就像一个黑盒子,无法知道服务器正在做什么;
复制拓扑
- 一主多备
场景:少量写、大量读
- 主-主(主动-主动)
(⊙o⊙)…MySQL不支持多主库复制
- 主-主(主动-被动)
构建容错性和高可用的强大方式,主要区别在于:其中一台服务器是只读的被动服务器,这种方式使得反复切换主动和被动服务器非常方便,因为服务器的配置是堆成的。使得故障转移和故障恢复很容易。它也可以让你在不关闭服务器的情况下执行维护、优化表、升级操作系统或者其他任务。
配置:
1)确保两台服务器上有相同的数据
2)启动二进制日志,选择唯一的服务器ID,并创建复制账号
3)启用备库更新的日志记录,这是故障转移和故障恢复的关键
4)把被动服务器配置成只读
5)启动每个服务器的MySQL实例
6)将每个主库设置为对方的备库,使用新创建的二进制日志开始工作
- 拥有备库的主-主结构
- 环形复制
环形结构非常脆弱,尽量避免
- 一个主库、一个分发主库和多个备库
分发主库也是一个备库,只是其他备库从这个分发主库来接收日志事件,降低主库的压力
- 树形或者金字塔形
好处是减轻主库的负担,缺点是中间层出现任何错误都会影响到多个服务器,中间层次越多,处理故障就会更困难、更复杂
用途建议
- 选择性复制
比如按部门,将数据复制到不同的数据库
- 分离功能
在主库上用作OLTP,在备库上作OLAP分析
- 数据归档
在备库上实现数据归档,保留主库上删除过的数据
- 将备库用作全文检索
- 只读备库
- 模拟多主库复制
- 创建日志服务器
创建没有数据的日志服务器,它的唯一目的就是更加容易重放并且过滤二进制日志事件,对崩溃后重启复制很有帮助
网友评论