数据库主从复制

主从复制原理

主从复制依赖于binlog；binlog中存储对数据库进行操作的sql语句；
从服务器每隔一段时间会对主服务器做一次扫描，探测数据是否发生改变，如果发生改变，则会开启一个IO线程请求binlog日志；同时主服务器会通知dump线程，为所有请求的服务器发送binlog日志。

单主复制

写入主节点的数据都需要复制到从节点，即存储数据库副本的节点。当客户要写入数据库时，他们必须将请求发送给主节点，而后主节点将这些数据转换为复制日志或修改数据流发送给其所有从节点。从使用者的角度来看，从节点都是只读的。

多主复制

也称为主主复制，数据库集群内存在多个对等的主节点，它们可以同时接受写入，每个主节点同时充当主节点的从节点。多主节点的架构模式最早来源于DistributedSQL这一类多数据中心跨地域的分布式数据库

复制类型

同步复制：Master提交事务，直到事务在所有slave都已提交，才会返回客户端事务执行完毕信息。万一主节点发生故障，总是可以在从节点继续访问最新数据。缺点则是：只要有一个同步的从节点无法完成确认（例如：由于从节点发生崩溃，或者网络故障，或任何其他原因 ），写入就不能视为成功，主节点会阻塞其后所有的写操作，直到同步副本确认已完成。因此，把所有从节点都配置为同步复制有些不切实际。因为这样子的话，任何一个同步节点的中断都会导致整个系统更新停滞不前。实践中，如果数据库启用了同步复制，通常意味着其中某一个从节点是同步的，而其他节点这是异步模式。万一同步的从节点变得不可用或性能下降，则将另一个异步的从节点提升为同步模式。这样可以保证至少有两个节点（即主节点和一个同步从节点）拥有最新的数据副本。这种配置有时候也叫做半同步。
异步复制：Master将事件写入binlog，自身并不知道slave是否接收是否处理，不能保证所有事务都被所有slave接收。MySQL 默认的复制就是异步的。MySQL主库将事件写入到Binlog文件中，此时主库只通知一下Dump线程发送这些新的Binlog，然后主库继续处理提交操作 ，不会保证这些Binlog传到任何一个从库节点上。但是因为主节点不关从节点是否收到Binlog，如果主crash掉了，此时主节点上已提交的事务可能并没有传到从库上，如果此时，强行将从节点提升为主节点，可能导致新的主节点上数据不完整。
半异步复制：介于全同步复制和全异步复制之间的一种，主库只需要等待至少一个从库节点收到Binlog并Flush Binlog到Relay log文件即可，主库不需要等待所有从库给主库反馈。（注意只要收到一个从库的反馈即可）

注：半同步复制功能要在Master和slave上开启才会起作用，只开启一边，依然是异步复制。

复制延迟

https://baijiahao.baidu.com/s?id=1716187911729308342&wfr=spider&for=pc
http://www.imxmx.com/Item/1/204987.html

延迟复制

https://blog.csdn.net/sj349781478/article/details/106385333

高可用性

系统中的任何节点都可能由于各种出其不意的故障而造成计划外停机；同时为了要维护系统，我们也需要一些计划内的停机。采用主从模式的数据库，可以防止单一节点挂起导致的可用性降低的问题。
系统可用程度一般使用小数点后面多个 9 的形式，如下表所示。

可用性	年故障时间
99.9999%	32秒
99.999%	5分15秒
99.99%	52分34秒
99.9%	8小时46分
99%	3天15小时36分

一般的生产系统都会至少有两个 9 的保证，追求三个 9。想要做到 4 个 9 是非常最具有挑战的。

在主从模式下，为了支撑高可用，就需要进行故障处理。我这里总结了两种可能的故障及其处理方案。

从节点故障。由于每个节点都复制了从主库那里收到的数据更改日志，因此它知道在发生故障之前已处理的最后一个事务，由此可以凭借此信息从主节点或其他从节点那里恢复自己的数据。

主节点故障。在这种情况下，需要在从节点中选择一个成为新的主节点，此过程称为故障转移，可以手动或自动触发。其过程为：

第一步根据超时时间确定主节点离线；
第二步选择新的主节点，这里注意新的主节点通常应该与旧的主节点数据最为接近；
第三步是重置系统，让它成为新的主节点。

这么设计该类系统的目的在于以下几点

获得更好的写入性能：使数据可以就近写入。
数据中心级别的高可用：每个数据中心可以独立于其他数据中心继续运行。
更好的数据访问性能：用户可以访问到距离他最近的数据中心。

但是，此方法的最大缺点是，存在一种可能性，即两个不同的节点同时修改相同的数据。这其实是非常危险的操作，应尽可能避免。

还有一种情况是处理客户端离线操作的一致性问题。为了提高性能，数据库客户端往往会缓存一定的写入操作，而后批量发送给服务端。这种情况非常类似于大家使用协作办公文档工具的场景。在这种情况下，每个客户端都可以被看作是具有主节点属性的本地数据库，并且多个客户端之间存在一种异步的多主节点复制的过程。这就需要数据库可以协调写操作，并处理可能的数据冲突。

典型的多主复制产品有 MySQL 的 Tungsten Replicator、PostgreSQL 的 BDR 和 Oracle 的 GoldenGate。

目前，大部分 NewSQL、DistributedSQL 的分布式数据库都支持多主复制，但是大部分是用 Paxos 或 Raft 等协议来构建复制组，保证写入线性一致或顺序一致性；同时传统数据库如 MySQL 的 MRG方案也是使用类似的方式，可以看到该方案是多主复制的发展方向。