《高性能MySQL》の复制

0x00前言

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

0x01简介

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

简要介绍复制如何工作

讨论基本的复制服务搭建

与复制相关的配置

如何管理和优化复制服务器

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 · 第三版》