数据库备份方案

借助第三方插件，可配合脚本实现

数据延时、一致性问题(宕机、故障等导致)Apache ShardingSphere：同一线程且同一数据库连接内，如有写入操作，其读操作均从主库读取，用于保证数据一致性

级联架构

slave

用户请求

5.请求指定范围数据

返回 ACK

因为读写请求都被分发到了不同的节点处理，所以吞吐量至少会提升50%以上，一主多从相较于单机节点而言，能够在性能上进一步提升。适用于一些读大于写的场景，反之多主一从架构适用于写大于读的场景。

master

master(备)

属于一主多从架构的升级版，毕竟如果一个主节点存在多个从节点时，多个从节点都会同时去主节点拉取新数据，如果数据量较大，就会导致主节点的I/O负载过高，因此这种级联复制架构要解决的问题，也就是多个从库会对主库造成太大压力的问题。

......

bin-log日志

主主模式下，两个主库都提供读写服务，如果应用通过两个主库操作相同数据，则会发生冲突导致数据覆盖(使用语句模式复制)或复制异常(使用行模式复制)，因此需要对读写服务进行控制：1、基于自主主键控制，通过设置自增属性auto_increment_offset和auto_increment_increment来控制每个主节点生产不同的自增值，并根据不同自增值访问不同主节点。2、基于库级别或表级别控制，如应用APP1访问节点node1上的DB1库，而应用APP2访问节点node2上的DB2库，两个主节点间不会操作相同表的数据，因此不会存在事务冲突。为保证应用程序使用相同数据库连接配置而不受故障切换影响，常用方案有：1、VIP，通过vrrpd或keepalived将VIP动态绑定到新主节点2、域名，通过切换域名将域名指向新主节点3、代理，通过更新代理中存放的路由信息来指向新主节点。三、双主架构优点1、主主模式能将读写请求分摊到两个主节点，有效提升服务器使用率。2、主节点发生故障后，能快速进行主从切换。3、当故障节点恢复后，故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。四、双主架构缺点1、当主节点上MySQL实例发生故障后，可能会存在部分数据(Binlog)未同步到另外的主节点，导致数据丢失(直到故障节点恢复)。2、主主模式下，很容易因数据访问控制不当导致数据冲突。3、为提高系统高可用性，双主架构会被扩展成双主多从结构，同样存在主节点发生故障后多个从库选主和恢复复制的问题。4.需要主备的IP在同一个网段。 5.提供的检测机制比较弱，需要自定义脚本来确定Master是否能提供服务，比如更新心跳表等。 6.无法保证数据的一致性7.keepalived软件自身的HA无法保证

复制集群3

https://www.cnblogs.com/wuxu/p/13161438.html

互为主从

数据同步

读请求

App(java/PHP...)

4.通知从节点

增删改操作

复制集群1

主从复制原理

写请求

MHAmanage

连接/工作线程

3.监听变化

client

VIP

场景分析：问题1用户注册成功后，需要进行登录操作，注册是写 操作，登录是读操作，如果此时从库还没有用户的注册信息，那么用户登录会失败。 解决方法： 这个问题可以在业务层进行处理，注册成功之后，马上登录的，访问主库； 这个问题也可以在访问从库失败之后，访问主库进行验证；问题2用户修改密码成功后，需要进行登录操作，修改是写 操作，登录是读操作，如果此时从库还没有更新用户的信息，那么用户登录会失败。 解决方法：此时从库的数据没有更新，如果用户登录会出现失败。可以在业务逻辑层进行处理，当用户密码修改后，在缓存中新增一条Id记录，记录用户的最新信息，并设置过期时间，每次请求的时候，先从缓存读取信息，如果没有在缓存读到，则到从库读取。

为何要备份？- 软件故障- 自然灾害- 黑客攻击- 误操作 (占比最大)没有完美的解决方案。只有合适的解决方案

MySQL8+keepalived双主热备高可用

keepalived

6.写入中继日志

2.记录日志

1.写入数据

复制集群2

font color=\"#323232\

读写请求

针对身份认证系统：推荐选择一主多从架构(读写分离)理由：1.架构简单，维护方便。2.租户/用户信息，组织机构信息，部门，菜单信息等基本上是很少改动了，即读多写少；3.注册及修改密码后立即登录操作及角色分配等要求数据实时性高，可针对性的解决，比如读主库，读缓存；4.选择半同步/同步模式解决数据丢失问题5.从库开启并行复制解决数据延迟问题

VIP = Virtual IP Address，虚拟IP地址，主要是用来进行不同主机之间的切换，如用在服务器的主从切换。

MySQL热备高可用MHA架构

7.监听变化

I/O线程

其他方式

一主一从/一主多从架构

relay-log日志

8.解析日志写入数据

发生灾难时需要多个数据副本？我能承受丢失数据的后果吗？需要增加读取和/或写入吞吐量？需要最小化停机时间？我的网络有多稳定？数据需要强一致性？

dump线程

半同步模式：当客户端的数据到来时，会先写入到主节点中，接着主节点会向所有从节点发送一个写入数据的请求，但半同步模式中无需等待所有从节点全部写入完成后再返回，而是只要有一个从节点写入成功并返回了ACK，则会直接向客户端返回写入成功，这样既能够保证性能，又能够确保数据不丢失。同时为了避免网络延迟造成主库长时间收不到从库的ACK，因此在配置半同步式复制时，会有一个rpl_semi_sync_master_timeout参数来控制超时时间，其默认值是10000ms/10s，如若主库在10s内依旧未收到从库的ACK，则会将复制模式切换成异步模式，切成异步模式后，会在后续网络正常后再次切回半同步模式。

SQL线程