KingbaseES R3读写分离集群工作机制（1）
一、kingbaseES R3读写分离集群架构
kingbaseES R3读写分离集群架构由两部分组成，后台的主备流复制和前端的kingbasecluster集群服务。
1）kingbasecluster服务主要用于对后台的数据库服务KingbaseES的健康状态进行检查；例如检查到主库的kingbaseES数据库服务down或者系统故障导致kingbaseES的数据库服务不能被访问，便会自动发起数据库的主备切换。
2）kingbaseES主备流复制服务，对于kingbasecluster来讲是起到后台的数据库服务的作用，用于数据库的主备同步、数据库的事务处理，对客户端的SQL语句进行处理和响应。
二、 kingbaseES R3读写分离集群工作原理
如上图1-2所示，主要分为以下几个流程：
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掉备库需要的元组信息。这个参数可以被用来排除由于记录清除导致的查询取消，但是可能导致在主库上用于某些负载的数据库膨胀。
kingbaseES 主备流复制：
-
同步流复制
当主库（Primary库）发生变化，比如有一条DML语句产生了WAL日志记录后，通过后台进程传送到备库（Standby库）后，备库必须要确认接收到这个日志，而后向Primary返回一个成功接收的信号，主库才可成功commit，并返回给Client。否则主库会一直等待到备库成功接收后，期间等待就是主库commit后返回成功的时间段。
对于同步流复制，依据配置参数synchronous_commit的不同配置（remote_write、on、remote_apply），主库在事务commit时，需要等待的时间段也不同。
这种方式各有利弊，一定要根据不同的应用场景进行使用，因为同步复制必须要等待备库接收完成后，主库才能返回commit成功，反之主库则一直等待，假如在一个繁忙的业务系统中，备库出现了问题或者网络出现波动，备库没有接收到或接收到后因为种种原因未能将信号返回主库，那么主库就会产生等待，业务就会停止，甚至数据库会出现假死、宕住状态。 -
异步流复制
异步流复制，字面不难不理解，就是与同步复制相反，即主库在做事务处理时，将WAL日志记录传递到备库，不需要等待备库确认接收完成，只需成功传递WAL日志即向Client返回commit。
这种复制方式相对同步复制的性能较好，在备库出现故障时不会影响主库业务正常进行，有人会想，那不是挺好的吗，但是就像上面我们说的，任何的高可用架构都不可能做到无缝、无间隙、无故障。异步流复制虽然有他的优势，但是也存在弱点，比如Primary库发生了变化，产生了WAL日志，但是还没等传递到备库。Primary就宕机了，那么备库切换成主库时就会丢数据！ 这种情况如果在主库完全崩溃、故障甚至坏块时，那么就是不可逆的了！
