误删数据恢复

1. 误删数据

传统的高可用架构是不能预防误删数据的，因为主库的一个 drop table 命令，会通过 binlog 传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。

怎么判断一个主库是否出了问题？

1. 主库监测

在一主一备的双 M 架构里，主备切换只需要把客户端流量切到备库；而在一主多从架构里，主备切换除了要把客户端流量切到备库外，还需要把从库接到新主库上。

读写分离，以及怎么处理主备延迟导致的读写分离问题。

1. 读写分离

读写分离的主要目标就是分摊主库的压力。一般有两种架构:

1. 客户端（client）主动做负载均衡，即由客户端自己选择连接的 mysql 服务器
2. 在 MySQL 和客户端之间有一个中间代理层 proxy，客户端只连接 proxy， 由 proxy 根据请求类型和上下文决定请求的分发路由。

两种架构的对比:

MySQL 主备切换策略，一主多从

1. 双主模型的主备切换策略

如图 1 所示就是基本的主备切换流程

正常情况下，只要主库执行更新生成的所有 binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。但是，MySQL 要提供高可用能力，只有最终一致性是不够的。由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。

MySQL 主备延迟与并行复制

1. 主备延迟

与数据同步有关的时间点主要包括以下三个：

1. 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
2. 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
3. 备库 B 执行完成这个事务，我们把这个时刻记为 T3。

所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。在网络正常的时候，日志从主库传给备库所需的时间是很短的，即 T2-T1 的值是非常小的。也就是说，网络正常情况下，主备延迟的主要来源是备库接收完 binlog 和执行完这个事务之间的时间差。所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

接下来内容与 MySQL 主从复制相关的内容，包括:

1. MySQL 如何保证主从同步的最终一致性，设计 binlog 同步过程和binlog 的格式
2. 主备延迟，以及并行复制
3. 由于主备延迟不可避免，因此由两种主备切换策略
4. 主从复制同步位点的判断以及GTID 模式
5. 读写分离，以及怎么处理主备延迟导致的读写分离问题
6. 主库的心跳信息监测，以便在主库故障时及时进行主备切换

1. 主备的基本原理

如图 1 所示就是基本的主备切换流程