主从复制如何工作
默认异步复制方式
- 主写 binlog、自行 commit
- 从的一个IO线程读主的 binlog，写到自己 relay_log 中
- 单线程(可配置)将 relay_log 的内容进行 replay(重放)，恢复数据
半同步复制方式
- 主从都需要安装插件
- 主写 binlog，等待
- 从读主的 binlog，写到自己的 relay_log 后，发还ack给主
- 主收到所有的 ack， commit
- timeout 内没有完成 ack，也会进行 commit
基于日志点复制和基于 GTID 方式复制
区别
基于日志点的复制
- 传统的主从复制方式
- slave 请求 master 的增量日志基于日志偏移量
从节点配置链路 (
change to master) 时需要指定master_log_file和master_log_ps参数基于 gtid 的复制
GTID，global transaction id
- source_id:transaction_id
- slave 增量同步 master 的数据依赖于其未同步的事务 id
- 配置复制链路时，slave 可以根据已经同步的事务 id 继续自动同步
特点
| 基于日志的复制 | 基于 GTID 的复制 |
|---|---|
| 兼容性好 | 同老版本的 MYSQL 和 MARIADB 不兼容 |
| 支持 MMM 和 MHA 架构 | 支持 MHA 架构 和 PXC的 gelara 架构 |
| 主备切换后很难找到新的同步点 | 基于事务 ID 复制，可以很方便的找到未完成同步的事务 ID |
| 方便的跳过复制错误 | 只能通过置入空事务(begin;commit) 方式跳过错误 |
选择
基于日志点
- 兼容老版本 mysql 和 mariadb
- 需要使用 mmm 架构
基于 gtid
- 除了上述外的场景，优先选择
MMM 和 MHA 高可用架构的优缺点
- replication 级别的
todo，没用过
MGR 的认识
- master group replication
todo，没用过
如何减少主从复制的延迟
坏 sql
数据变化大的事务
- 切分事务中的数据，即分批更新数据
大表的 DDL
- 使用 percona toolkit 的
pt-online-schema-change工具进行 DDL 操作
网络延迟
- 减少单次事务处理的数据量，以减少产生的日志文件大小
- 避免网络带宽不足，减少 master 节点挂载的 slave 的数量
slave 的单线程 replay relaylog 的速度跟不上 master 写入
- master 可以多线程写入，导致 binlog 很快的增长
- slave 对同步后的 replaylog 进行 replay，由于默认单线程，重放效率跟不上
- 解决
- 5.7 后使用多线程复制
- 使用 MGR 复制架构
如何解决 db 读写负载大的问题
读
- 配置多个 slave
- 使用 mycat 等中间件进行读写分离，将读请求分担到 slave 上
- 使用 mycat 等中间件进行负载均衡
写
- 使用数据库中间件进行分库分表
- 分库：垂直切分
- mycat 划分不同的 schema
- 分表：水平切分
- mycat 使用分片逻辑
- db 本身可以使用表空间划分
- 分库：垂直切分
若有收获，就点个赞吧
0 人点赞
