GPDB - 高可用特性 - 同步复制与异步复制

GPDB - 高可用特性 - 同步复制与异步复制

GreenPlum是基于PostgreSQL的分布式数据库,master用于接收用户请求并生成执行计划与分发,当然也可以参与计算;而segment则用于存储数据,将计算的结果传递给master。Segment本身具有高可用特性,即分为primary和mirror,通过主从复制构建高可用关系。默认使用同步复制,若FTS检测到mirror发生异常,则修改为异步复制。本文关注如何从同步复制切换到异步复制。

1、几个重要配置项

1)synchronous_commit

当数据库提交事务时是否需要等待WAL日志写入磁盘才向客户端返回。该参数可选值为on、off、local、remote_apply、remote_write。参数值说明如下图所示:

GPDB - 高可用特性 - 同步复制与异步复制_第1张图片

根据synchronous_commit参数,对应的同步复制可以分为3种模式:WRITE、FLUSH、APPLY。复制过程中,每个备机都有自己的复制模式,主机根据不同的备机模式决定事务提交是否需要等待备机。GPDB中该参数默认是on,也就是primary要等待mirror将接收到的WAL持久化到磁盘才可以提交

2)synchronous_standby_names

该参数是PG带过来的,用于设定需要支持同步复制的备节点服务器名称列表。必须与备机的application_name一样。有3种语法格式,如下:

[FIRST] num_sync (standby_name [,...])
ANY num_sync (standby_name [,...])
standby_name [,...]

其中

1)num_sync表示事务需要等待响应的同步备节点个数

2)standby_name表示同步复制备节点服务器名字,这里指备节点连接配置信息中的application_name,对于流复制,可以查看recovery.conf配置文件(PG12开始,在postgresql.conf)中的primary_conninfo配置项,缺省值是walreceiver。对于逻辑复制可以在订阅连接信息中设置,缺省值是订阅名本身

3)FIRST和ANY指定从列表中选择同步备节点的方法。大小写不敏感。FIRST表示基于优先级的同步复制,ANY表示基于法定人数的同步复制

4)第3种格式在PG9.6版本之前使用,现在仍然支持,等价于FIRST 1(...)。比如FIRST 1(s1,s2)与s1,s2等价。

例1:FIRST 2(s1,s2,s3,s4):规定每个事务必须等待优先级最高的2个备节点确认才能提交,该列表排的越靠前的名字优先级越高。本例中s1>s2>s3>s4。没排在前2位的备节点都属于潜在的同步备节点。

例2:ANY 2(s1,s2,s3):规定每个事务必须等待至少任意2个节点确认后才能提交。

在GPDB中,对于异步复制,该参数配置为空;对于同步复制,配置为“*”,表示匹配任意备名称这里需要注意,GPDB中segment对于该值默认为空,通过fts将其更改为“*”,然后保存到postgresql.auto.conf文件中,以此达到同步复制的目的

2、同步复制情况下的提交

关于WaitEventSet及Latch的唤醒,参考前文:

https://mp.weixin.qq.com/s?__biz=MzU1OTgxMjA4OA==&mid=2247485254&idx=1&sn=c4e84024a01dbb27b5c449e7658cbacd&chksm=fc10dbd1cb6752c702b7df959d7b233c72bf9971e34006461c5a815f623b2af1a9b15e6fc40b&token=2029515501&lang=zh_CN#rd

https://mp.weixin.qq.com/s?__biz=MzU1OTgxMjA4OA==&mid=2247485259&idx=1&sn=62332c14bf4a4cd5c01fcf49455b3ed4&chksm=fc10dbdccb6752ca94325ff9124b576bde5db0d953ac5a736745a91d2f37799307f67ed4a8ef&token=2029515501&lang=zh_CN#rd

下图为同步复制正常场景下,commit流程被唤醒的逻辑:

GPDB - 高可用特性 - 同步复制与异步复制_第2张图片

1、事务提交

1)事务提交时RecordTransactionCommit->SyncRepWaitForLSN进入同步复制等待。上图所示,会将等待进程MyProc插入WalSndCtl->SyncRepQueue[mode]队列中,以供sender进程向mirror发送WAL接收到mirror落盘回复后,唤醒等待;

2)WaitLatch进入同步复制等待,mirror回复唤醒WaitLatch后,进入MyProc->syncRepState判断,同步复制完成,break退出循环,事务提交流程可继续下去。

2、WaitLatch

epoll_create -- epoll_ctl -- epoll_wait进入等待,通过监控管道上EPOLLIN事件进行等待与唤醒。

3、WalSndLoop sender进程主函数

Sender进程接收到mirror的回复后,通过SyncRepReleaseWaiters来唤醒等待进程。分为3种同步模式的队列,若mirror回复wal已接收到了,则通过SyncRepWakeQueue处理等待队列

4、SyncRepWakeQueue

将可唤醒的进程从队列种删除,然后SetLatch设置latch的is_set为true,并通过kill命令向事务提交进程(等待进程)发送SIGUSR1信号。

为什么还要发送信号呢?

因为sender进程和commit进程属于不同进程,sender进程置位后,commit进程是看不见的,所以还需要发送信号给commit进程.

Commit进程使用的是MyLatch,而这里队列中的是MyProc->procLatch,是否同一个?

GPDB - 高可用特性 - 同步复制与异步复制_第3张图片

进程初始化的时候,可看到MyLatch就是MyProc->procLatch.

5、SyncRepWakeQueue

Commit进程在InitPostgres前就注册了SIGUSR1信号处理函数procsignal_sigusr1_handler:由于MyLatch->is_set还是false,所以将其值置为true,然后sendSelfPipeByte向selfpipe_writefd管道写一个字节。因为epoll_wait监控的是管道上的EPOLLIN事件,写入一个字节后,commit进程的epoll_wait就被唤醒了。

3、切换异步复制

切换异步复制的流程如下图所示:

GPDB - 高可用特性 - 同步复制与异步复制_第4张图片

1)事务提交时RecordTransactionCommit->SyncRepWaitForLSN进入同步复制等待。上图所示,会将等待进程MyProc插入WalSndCtl->SyncRepQueue[mode]队列中,以供sender进程向mirror发送WAL接收到mirror落盘回复后,唤醒等待;

3)这里关注for循环,WaitLatch何时被唤醒。FTS进程探测到mirror异常,需要关闭同步:UnsetSyncStandbysDefined会修改synchronous_standby_names为空,即改为异步,然后持久化到postgresql.auto.conf中,最好通过pg_reload_conf函数(通知所有进程更新配置)向Postmaster(主进程)进程发送SIGHUP信号

4)主进程处理SIGHUP信号的函数为SIGHUP_handler,该函数会向所有子进程包括后台进程发送SIGHUP信号。这里关注checkpoint进程

5)checkpoint进程接收到SIGHUP信号后,ChkptSigHupHandler将got_SIGHUP变量置为true,然后checkpoint进程轮一圈后,会判断该参数,若为true则调用UpdateSharedMemoryConfig函数

6)UpdateSharedMemoryConfig->SyncRepUpdateSyncStandbyDefined函数会根据synchronous_standby_names是否为空判断同步异步情况,若为异步,则会调用SyncRepWakeQueue处理所有同步等待的进程

7)SyncRepWakeQueue将进程的syncRepState标记为SYNC_REP_WAIT_COMPLETE,然后向该进程发送SIGUSR1信号

8)事务等待进程通过procsignal_sigusr1_handler处理SIGUSR1信号,通过管道唤醒等待进程的epoll_wait

9)SyncRepWaitForLSN的WaitLatch被唤醒后,继续for循环,此时MyProc->syncRepState已在7)标记为了SYNC_REP_WAIT_COMPLETE,所以会退出循环,不再等WAL的LSN确认了。至此,完成异步复制的切换。

注意:主进程SIGHUP_handler会向所有子进程发送SIGHUP信号,也就是事务等待进程也会接收到SIGHUP信号,它处理SIGHUP信号的函数是PostgresSigHupHandler,会SetLatch MyLatch。那么上图的SyncRepWaitForLSN的WaitLatch也会被唤醒,然后继续循环,但是MyProc->syncRepState还未更改为SYNC_REP_WAIT_COMPLETE,仍旧会进入WaitLatch等待。当然,这还得checkpoint进程来唤醒让同步复制不在等待而赶紧走掉:

PostgresMain
  pqsignal(SIGHUP, PostgresSigHupHandler);
  |--  {
  |    ConfigReloadPending = true;
  |    SetLatch(MyLatch);
  |--  }

你可能感兴趣的:(GPDB - 高可用特性 - 同步复制与异步复制)