KingbaseES主备流复制讲解

一、KingbaseES 主备流复制架构

1、KingbaseES主备流复制

walsender：用于主库发送WAL日志记录至从库

walreceiver：用于从库接收主库的WAL日志记录

startup：用于从库apply日志

如图所示

二、KingbaseES主备流复制工作机制

1、主备数据库启动，备库启动walreceiver进程，wal进程向主库发送连接请求

2、主库收到连接请求后启动walsender进程，并与walreceiver进程建立tcp连接

3、备库walreceiver进程发送最新的wal LSN给主库

4、主库进行lsn对比，定期向备库发送心跳信息来确认备库可用性，并且将没有传递的wal日志进

     行发送

5、备库调用操作系统write() 函数将wal写入缓存，然后调用操作系统fsync() 函数将wal刷新到磁 

     盘，然后进行wal回放。同时备库向主库返回ack信息，ack信息中包含write_lsn、flush_lsn、

     replay_lsn，这些信息会发送给主库，用以告知主库当前wal日志在备库的应用位置及状态，相

    关位置信息可以通过sys_stat_replication视图查看

6、如果启用了hot_standby_feedback参数，备库会定期向主库发送xmin信息，用以保证主库不会

     vacuum掉备库需要的元组信息。这个参数可以被用来排除由于记录清除导致的查询取消，但

     是可能导致在主库上用于某些负载的数据库膨胀

三、同步流复制

1、当主库(Primary库)发生变化，比如有一条DML语句产生了WAL日志记录后，通过后台进程传送

      到备库(Standby库)后，备库接收到这个日志，而后向Primary返回一个成功接收的信号，主库

      才可成功commit，并返回给Client。否则主库会一直等待到备库成功接收日志，期间等待就是

      主库commit后返回成功的时间段

2、对于同步流复制，依据配置参数synchronous_commit的不同配置 (remote write、on、remote

     apply)，主库在事务commit时，需要等待的时间段也不同。当然也可以配置相应的timeout的

     闻值，超过闽值后，同步转为异步

3、这种方式各有利弊，一定要根据不同的应用场景进行使用，因为同步复制必须要等待备库日志

      接收完成后，主库才能返回commit成功，反之主库则一直等待，假如在一个繁忙的业务系统

      中，备库出现了问题或者网络出现波动，备库没有接收到日志或接收后因为种种原因未能将信

      号返回主库，那么主库就会产生等待，业务就会停止，甚至数据库会出现假死、宕住状态

四、异步流复制

1、异步流复制，字面不难不理解，就是与同步复制相反，即主库在做事务处理时，将WAL日志记

     录传递到备库，不需要等待备库返回接收到的确认，只需成功将WAL日志发送到备库后即向

     Client返回commit

2、这种复制方式相对同步复制的性能较好，在备库出现故障时不会影响主库业务正常进行，有人

     会想，那不是挺好的吗？但是就像上面我们说的，任何的高可用架构都不可能做到无缝、无间

     隙、无故障。异步流复制虽然有他的优势，但是也有在弱点，比如Primary库发生了变化，产生

     了WAL日志，但是还没等传递到备库。Primary就宕机了，那么备库切换成主库时就会丢数据

 
      这种情况如果在主库完全崩溃、故障甚至坏块时，那么就是不可逆的了

 

五、KingbaseES主备流复制日志同步机制

1、事务commit后，日志在主库写入wal日志，还需要根据配置的日志同步级别，等待从库反馈的

      接收结果

2、主库通过日志传输进程将日志块传给从库，从库接收进程收到日志开始回放，最终保证主从数

      据一致性

下图我们可以看到流复制中日志提交的大致流程

六、主备流复制同步模式讲解

通过在 kingbas.conf 配置 synchronous_commit 参数来设置同步级别

如图所示

synchronous_commit = off # synchronization level; # off local, remote_write, or on

1、remote_apply: 事务commit或rollback时，等待其redo在primary、以及同步standby(s)已持久

     化，并且其redo在同步standby*(s)已apply。一般用于对于读写分离一致性要求较高的场景，主

     库写入后，需要立刻在备库进行查询的需求，此配置对主库的性能影响较大

2、on: 事务commit 或 rollback时，等待其redo在primary、以及同步standby(s)已持久化

      (默认为on)

3、remote_write: 事务 commit 或 rollback时，等待其redo在primary已持久化。其redo在同步

      standby(s)已调用write接口 (写到 os,但是还没有调用持久化接口如fsync)

4、local: 事务commit 或 rollback时，等待其redo在primary已持久化

5、off: 事务commit 或 rollback时，等待其redo在primary已写入wal buffer，不需要等待其持久化

     对主库事务提交性能的影响从高到低依次是: remote apply>onremote write>local>of

七、级联复制(Cascading Replication)

1、级联复制特性允许一台standby服务器接收复制连接并且把 WAL 日志流传送给其他standby服

      务器，就像一个中转器一样。这可以被用来减小对于master节点的直接连接数并且使得节点间

      的带宽开销最小化

2、一台同时扮演着接收者和发送者角色的standby服务器被称为一台级联standby服务器，"更直

      接" (通过更少的级联后备服务器)连接到master节点的standby服务器被称为上游服务器

      (Upstream)，而那些离得更远的standby服务器被称为下游服务器。级联复制并没有对下游服

      务器的数量或布置设定限制

3、一台级联standby服务器不仅仅发送从master节点接收到的 WAL 日志流，还要发送那些从归档

      中恢复的记录。因此即使某些上游连接中的复制连接被中断，只要还有新的 WAL 记录可用，

      下游的流复制都会继续下去

   

       注：级联复制目前是异步的

八、延迟复制 (Delay Replication)

1、某些情况下，一个后备服务器会尽快恢复来自于主服务器的 WAL 记录。有一份数据的延时拷

     贝是有用的，它能提供机会纠正数据丢失错误。这个参数允许你将恢复延迟一段固定的时间，

     如果没有指定单位则以毫秒为单位。例如，如果你设置这个参数为5min，对于一个事务提交，

     只有当后备机上的系统时钟超过主服务器报告的提交时间至少 5分钟时，后备机才会重放该事

     务，可用于一主多备时构建容灾备库

2、延迟备库的搭建很简单，只要在 recovery.conf (kingbase.auto.conf,R6版本) 里面增加个配置项

      即  recovery_min_apply_delay = 1min # 这里我测试就设置1分钟的延迟

       ## 默认的支持时间单位为 ms、s、min、h、d即毫秒，秒，分钟，小时，天等

九、主备流复制主要配置参数

1、主备流复制，因此需要在主机的数据节点上，对kingbase.conf文件需要配置以下参数

       hot_standby 必须始终将 hot_standby 设置为on，因为repmgr 需要能够连接到它管理的每个

      服务器

2、wal_leve 必须是replica 或 logical之一

3、max_wal_senders 必须设置为2或更大的值。通常，每个备用数据库都需要一个 WAL 发送者，

     它将附加到 KingbaseES实例上另外，repmgr 将需要两个免费的 WAL 发送者，以便克隆其他

     备用数据库。应该在复制群集中的所有 KingbaseES实例上将 max_wal_senders 设置为适当的

     值，这些实例可能会成为主服务器或 (在级联复制中) 备用数据库的上游服务器

4、max_replication_slots 如果打算使用复制插槽，则必须将 max_replication_slots 设置为非零

      值。应该在复制群集中的所有KingbaseES 实例上将 max_replication_slots 设置为适当的值，

       这些实例可能会成为主服务器或 (在级联复制中) 备用数据库的上游服务器

5、wal_log_hints如果打算使用 sys_rewind，并且未使用数据校验和初始化集群，则可能需要考虑

      启用 wal_log_hints

6、archive_mode 建议将 archive_mode 设置为on

7、wal_keep_segments通常，不需要设置 wal_keep_segments  (默认值: 0)，因为这不是确保所

      有必需的WAL段都可供备用使用的可靠方法。建议使用复制插槽和/或存档解决方案

       (例如 arman)，以确保备用数据库始终具有可靠的 WAL段来源

十、查看主备流复制状态

对于流复制同步模式，ACK响应将备节点内部信息发送主节点，包含以下几个项目

1、sent_Isn：主库发送的最新WAL日志的LSN位置

2、write_Isn：备库已写入的最新WAL日志的LSN位置

3、flush_Isn：已刷新的最新WAL日志的LSN位置

4、replay_Isn：startup进程最新应用的wal数据的LSN位置，发送此ACK的时间戳

     walreceiver不仅在写入和刷新WAL数据的时候返回ACK响应，还定期发送备节点心跳

 
     (心跳发送间隔通过wal_receiver_status_interval设置，默认10秒)。因此，主节点始终掌握所有

   

       已连接备节点的状态

通过对几个LSN位置之间对比，可以判断主库的负载状态及备库复制的延迟情况

十一、查看主备流复制复制槽状态

1、复制槽提供了一种自动化的方法来确保主库在所有的后备机收到 WAL 段 之前不会移除它们，

      并且主库也不会移除可能导致恢复冲突的行，即使备库断开也是如此

2、作为复制槽的替代，也可以使用wal_keep_size阻止移除旧的 WAL 段，或者使用

     archive_command把段保存在一个归档中。不过，这些方法常常会导致保留的 WAL 

     段比需要的更多，而复制槽只保留已知所需要的段。另一方面，复制槽可以保留很多的WAL段

     以至于它们填满了分配给sys_wal的空间; max_slot_wal_keep_size限制复制所保留的WAL文件

     的大小。类似地，hot_standby_feedback 和 vacuum_defer_ceanup_age保护了相关行不被

     vacuum 移除，但是前者在备库断开期间无法提供保护，而后者则需要被设置为一个很高 的值

     已提供足够的保护，复制槽克服了这些缺点

主备流复制正常状态下，备库的复制槽状态是 'active =t' ，如果复制槽状态不正常，则流复制状态应该是异常的，可以通过备库sys_log查看具体的故障信息

3、复制槽维护

删除复制槽

创建复制槽

十二、查看主备流复制同步模式

1、Sync_state字段信息

Async: 异步

Sync:同步

Quorum:同步

流复制状态说明 (state字段) 

1、刚开始建立流复制状态为startup

2、流复制建立成功后，开始追赶数据状态为catchup

3、数据追赶完成，正常同步数据时状态为streaming

4、如果正在关闭流复制连接，状态为stopping

一般情况下，流复制都应该处于streaming状态

2、synchronous_standby_names 参数

参数 synchronous_standby_names 是否有值决定了备机是否为同步/异步，简要描如下

KingbaseES 集群流复制基本原理讲解完成