0x00前言

本书讲述到定稿前的MySQL5.5版，所以下面内容的适用范围止步于MySQL5.5。本文仅仅强调书中讲述的重中之重， 以便快速查阅，详细的内容还请认真阅读书本和MySQL的官方文档。

0x01简介

本章阐述所有与复制相关的内容

• 简要介绍复制如何工作
• 讨论基本的复制服务搭建
  1. 与复制相关的配置
  2. 如何管理和优化复制服务器

0x02复制概述

• MySQL支持两种复制方式：基于行的复制和基于语句的复制。
• 都是通过主库上记录二进制日志，虽然有开销，但是不会很大。
• 同一时间点备库上的数据可能与主库存在不一致性，并无法保证主备之间的延迟。
• 通过复制可以将读操作指向备库来获得更好地读扩展。
• 目前备库只能串行化执行。

复制解决的问题

• 数据分布
• 负载均衡
• 备份
• 高可用性和故障切换
• MySQL升级

复制如何工作

• 主库把数据更改记录到二进制日志中。
• 备库将主库上的日志复制到自己的中继日志中。
• 备库读取中继日志中的事件，将其重放到备库数据之上。

<!-- more -->

0x03配置复制（略）

0x04复制的原理

现在一般使用基于行的复制更佳。

基于语句的复制（逻辑复制）

优点

• 实现相当简单
• 不用太多带宽
• 容易理解

缺点

• 很多情况无法正确复制，如使用了now()等函数
• 若使用了触发器或者存储过程也最好不要使用

基于行的复制

优点

• 减少锁的使用，更高效地复制数据
• 占用更少的CPU
• 解决数据不一致的情况

缺点

• 无法知道服务器正在做什么
• 无法处理诸如在备库修改表的schema的情况
• 带宽较高

0x05复制拓扑（往后补充图）

MySQL的复制有一个限制：每个备库只能有一个主库，但是可以用一些其他方法来解决这样的限制。

一主库多备库（多用于备份和读写分离）

备库之间根本没有交互。有以下用途：

• 为不同的角色使用不同的备库
• 可把一个备库当做代用的主库
• 把备库放在远程数据中心，用作灾难恢复
• 备份，培训，开发，测试

主动-主动模式下的主-主复制

用于两个处于不同地理位置的办公室，并且都需要一份可写的数据拷贝。弊大于利。

主动-被动模式下的主-主复制

切换主动被动服务器很方便。

拥有备库的主-主结构（用于增加冗余）

环形复制（要避免成环）

主库、分发主库以及备库

• 当备库足够多时。会对主库造成很大的负载，于是需要采用blackhole存储引擎的分发主库。
• 不一定只使用一个分发主库。
• blackhole表没有任何数据，但是目前有bug

树或金字塔形

定制的复制方案

• 选择复制性
• 分离功能（分离OLTP和OLAP）
• 数据归档
• 将备库用作全文索引
• 只读备库
• 模拟多主库复制
• 创建没有数据的日志服务器

0x06复制和容量规划

主备库的模式下，并不是增加备库就能线性增加读写功能。并且在开启复制功能时，要考虑监控延时，可用性。

0x07 MySQL复制的高级特性

半同步复制

可以帮助确保备库拥有主库数据的拷贝，减少潜在的数据丢失危机。有助于备库提供更好地冗余度和持久性。 半同步复制在提交过程中增加一个延迟：当提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输 到至少一台备库上。

• 在主库上已经完成事务提交，只有通知客户端被延迟了。
• 备库在接收到事务后发送反馈而非（备库）完成事务后发送。
• 如果备库一直没有回应已收到事件，会超时并转化为正常的异步复制模式。

复制心跳

保持备库一直与主库相联系，避免悄无声息地断开连接。

0x08小结

• KISS原则（Keep It Simple Stupid），用简单的就好。
• 监控，监控，监控，重要的事情说三遍。
• 理解复制的异步本质，且设计你的应用避免或容忍从备库读取脏数据。
• 在一个复制拓扑中不要写入多于一个服务器，把备库配置为只读，并降低权限以阻止对数据的改变。
• 打开本章锁讨论的明智且安全的设置。（往后补充）

引用

《高性能MySQL · 第三版》