高可用（一）

1、高可用：缩短维护或突发状况导致的停机时间，提高系统和应用的可用性；

• 高可用集群是一组计算机，作为整体向用户提供服务，出现故障时可以i安静故障机器的服务、资源、IP等都转移到另一台服务器上从而保证业务的正常进行。

• 高可用架构 HAS（接管数据库的启停、检测节点状态、自动主备切换）+DCS（记录集群关键信息）+VIP（对应用提供数据库连接服务）

2、流复制：将主机对数据的修改日志（wal日志）同步至备机，备机进行回放，将日志还原为数据修改已达到数据持久化。

• 只能对VBG100实例级进行复制

  只能对DDL定义语言进行复制

  流复制主库可读写，备库只读不可写

• 流复制相关线程：

  主库walsender：用于发送xlog日志记录 （一个主机可以有多个walsender给备机传送日志，但备机只有一个walreceiver，从唯一指定的主机复制日志）

  备库walreceiver：用于接收xlog日志记录

  备库startup：用于应用xlog日志记录

• 流复制过程

  备库启动startup - 备库启动walreceiver - walrceiver向主节点发送连接请求 （备机只在建立连接请求一次，后续由主机主动记录并发送）- 主节点收到请求后启动walsender，

• 流复制方式

• 异步流复制：默认是异步，如果主机崩溃，则某些未提交的事务可能还没还原到从服务器，导致数据丢失

  同步流复制：保证一个事务的所有修改都传送至从服务器。写事务提交后一直等待，知道该提交到备库指定位置（由synchronous_commit的值来指定)。数据丢失的唯一可能性是主服务器和从服务器同时崩溃

  • synchronous_commit参数：用于指定在命令返回“success”指示前，事务需要等待wal记录到达的位置

  • 单机状态下

    on/local/true/yes/1 :事务提交时，要等待wal日志写入磁盘文件才返回客户端success

    off/false/no/0： （是默认方式）事务提交时，wal日志写入wal_buffer则可以返回客户端

  • 集群流复制状态下

    异步复制 off/false/no/0 : 提交事务时，wal日志写入主库的wal_buffer则返回success

                local ：提交事务时，wal日志写入主库磁盘则返回success
    

    同步复制 remote_receive : 主库提交事务时，要等待备库接收到wal日志（也就是wal日志写入到备库的缓存）

                on/true/yes/1 ：（是默认方式）主库提交事务后，等备库接收到主库发送的wal日志并写入磁盘
    
                remote_apply/2 ：主库提交事务时，要等待备库完成对应部分回放
    

image.png

• 参数对性能的影响：remote_apply>on>remote_receive>of

3、备库同步

• 同步复制的备库列表（synchronous_standby_names参数指定）剩余的为异步复制

  standby_names[..,..] 指定多个备库，第一个为同步备库，其余是潜在备库

  [FIRST]num_sync(standby_name[..,..]) 基于优先级设置流复制备库，num_sync指定同步备库数量，主库提交事务时，至少等到num_sync个备库处理完wal才能向客户返回成功

  ANY num_sync(standby_name[..,..])基于quorum仲裁方式设置流复制备库，同步备库为任意num_sync个，主库提交事务时，至少等到num_sync个备库处理完后才向客户端返回成功

  *表示任意后备名称synchronous_standby_names=‘*’ 任意一个备节点为sync，剩下都都potential；synchronous_standby_names=‘FIRST 2（*）所有备节点中有两个为sync，其余剩下的是potential；synchronous_standby_names=’ANY 2(*)‘ 所有节点都是quorum状态，至少等待任意两个节点对wal进行处理后再返回客户端

• 备库同步状态

  sync 同步备库，进行同步复制

  asyncy 异步备库，进行异步复制

  potential 潜在同步备库，进行异步复制，当同步服务器中的一个出现故障，就可能变成同步服务器

  quorum 仲裁备用服务器的候选库

• 同步备库出现故障，导致主库一直处于等待状态

  解决方法是设置主机 most_available_sync=on 备机同步失败时不阻塞主机（开启后，主机事务只等待正常运行的备机节点的同步。默认值为off）

• 备库延迟回放 recovery_min_apply_delay = 0默认 其余整型；当备库延迟回放 synchronous_commit=remote_apply时，延迟回放的备库要设置为异步复制，否则会导致主库阻塞。同时会导致hot_standby_feedback被延迟，导致主服务器膨胀，二者使用要小心

4、wal日志回放

• wal日志回放是指将wal日志中记录的变更重新应用到系统、页面中的过程，通常发生在实例故障恢复的情况下、或主备实例间的数据同步状态

• 串行回放：通常情况下，wal日志回放因日志依赖先后顺序，一般采用单线程串行回放（无法充分利用物理环境资源，回放效率低）

• 并行回放：使用多线程并行方式回放日志，充分利用服务器资源，加快回放速度。分配模块负责解析和分配日志到回放模块来消费、回放日志。

  • recovery_max_worker 并行回放最大线程数，默认值1 （0-20）
  • recovery_parse_workers、 recovery_redo_workers都要设置为1
  • recovery_parallelism 查询实际回放线程个数，受前两个参数影响，任意值大于0时都会被重新计算

• 极致RTO

  开启极致RTO可以减少主机故障后数据恢复时间，提高可用性。可支撑数据库主机重启后快速恢复场景、主机和备机通过日志同步，加速备机回放的场景。

  • 不支持备机读，不支持主备从场景（replication_type=0）,否则数据库无法拉起
  • recovery_parse_workers指极致RTO中ParseRedoRecord线程（负责日志解析）的数量 默认1 （1-16）
  • recovery_redo_workers 指极致RTO中ParseRedoRecord线程对应的ParseRedoWorker数量 默认1 （1-8）
  • 极致RTO配置注意事项
    若同时开启recovery_ parse workers和recovery_ max workers,并行回放特性失效
    极致RTO不支持hot standby模式和主备从模式(replication _type=0)
    极致RTO也不支持列存，在已经使用列存表或者即将使用列存表的系统中，请关闭极致RTO

5、流复制监控

6、主备切换、备机重建和双主处理