PgSQL · 特性分析 · PG主备流复制机制

布满荆棘的人生 2022-07-14 18:48 167阅读 0赞

###  ###

PostgreSQL在9.0之后引入了主备流复制机制，通过流复制，备库不断的从主库同步相应的数据，并在备库apply每个WAL record，这里的流复制每次传输单位是WAL日志的record。而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后，才把WAL日志文件传送到备库，这样的方式导致主备延迟特别大。同时PostgreSQL9.0之后提供了Hot Standby，备库在应用WAL record的同时也能够提供只读服务，大大提升了用户体验。

## 主备总体结构 ##

PG主备流复制的核心部分由walsender，walreceiver和startup三个进程组成。  
walsender进程是用来发送WAL日志记录的，执行顺序如下：

PostgresMain()->exec_replication_command()->StartReplication()->WalSndLoop()->XLogSendPhysical()

walreceiver进程是用来接收WAL日志记录的，执行顺序如下：

sigusr1_handler()->StartWalReceiver()->AuxiliaryProcessMain()->WalReceiverMain()->walrcv_receive()

startup进程是用来apply日志的，执行顺序如下：

PostmasterMain()->StartupDataBase()->AuxiliaryProcessMain()->StartupProcessMain()->StartupXLOG()

下图是PG主备总体框架图：

![PG主备总体框架图][PG]

图1. PG主备总体框架图

## walsender和walreceiver进程流复制过程 ##

walsender和walreceiver交互主要分为以下几个步骤：

1.  walreceiver启动后通过recovery.conf文件中的primary\_conninfo参数信息连向主库，主库通过连接参数replication=true启动walsender进程；
2.  walreceiver执行identify\_system命令，获取主库systemid/timeline/xlogpos等信息，执行TIMELINE\_HISTORY命令拉取history文件；
3.  执行wal\_startstreaming开始启动流复制，通过walrcv\_receive获取WAL日志，期间也会回应主库发过来的心跳信息(接收位点、flush位点、apply位点)，向主库发送feedback信息(最老的事务id)，避免vacuum删掉备库正在使用的记录；
4.  执行walrcv\_endstreaming结束流复制，等待startup进程更新receiveStart和receiveStartTLI，一旦更新，进入步骤2。

![PG流复制过程][PG 1]

图2. PG流复制过程

## walreceiver和startup进程 ##

startup进程进入standby模式和apply日志主要过程：

1.  读取pg\_control文件，找到redo位点;读取recovery.conf，如果配置standby\_mode=on则进入standby模式。
2.  如果是Hot Standby需要初始化clog、subtrans、事务环境等。初始化redo资源管理器，比如Heap、Heap2、Database、XLOG等。
3.  读取WAL record，如果record不存在需要调用XLogPageRead->WaitForWALToBecomeAvailable->RequestXLogStreaming唤醒walreceiver从walsender获取WAL record。
4.  对读取的WAL record进行redo，通过`record->xl_rmid`信息，调用相应的redo资源管理器进行redo操作。比如heap\_redo的XLOG\_HEAP\_INSERT操作，就是通过record的信息在buffer page中增加一个record：
    
        MemSet((char *) htup, 0, sizeof(HeapTupleHeaderData));
         /* PG73FORMAT: get bitmap [+ padding] [+ oid] + data */
         memcpy((char *) htup + offsetof(HeapTupleHeaderData, t_bits),
         	   (char *) xlrec + SizeOfHeapInsert + SizeOfHeapHeader,
         	   newlen);
         newlen += offsetof(HeapTupleHeaderData, t_bits);
         htup->t_infomask2 = xlhdr.t_infomask2;
         htup->t_infomask = xlhdr.t_infomask;
         htup->t_hoff = xlhdr.t_hoff;
         HeapTupleHeaderSetXmin(htup, record->xl_xid);
         HeapTupleHeaderSetCmin(htup, FirstCommandId);
         htup->t_ctid = xlrec->target.tid;
        
         offnum = PageAddItem(page, (Item) htup, newlen, offnum, true, true);
         if (offnum == InvalidOffsetNumber)
         	elog(PANIC, "heap_insert_redo: failed to add tuple");
        
         freespace = PageGetHeapFreeSpace(page);		/* needed to update FSM below */
        
         PageSetLSN(page, lsn);
        
         if (xlrec->flags & XLOG_HEAP_ALL_VISIBLE_CLEARED)
         	PageClearAllVisible(page);
        
         MarkBufferDirty(buffer);
    
    还有部分redo操作(vacuum产生的record)需要检查在Hot Standby模式下的查询冲突，比如某些tuples需要remove，而存在正在执行的query可能读到这些tuples，这样就会破坏事务隔离级别。通过函数ResolveRecoveryConflictWithSnapshot检测冲突，如果发生冲突，那么就把这个query所在的进程kill掉。
5.  检查一致性，如果一致了，Hot Standby模式可以接受用户只读查询；更新共享内存中XLogCtlData的apply位点和时间线；如果恢复到时间点，时间线或者事务id需要检查是否恢复到当前目标；
6.  回到步骤3，读取next WAL record。

![PG rstandby模式和apply日志过程][PG rstandby_apply]

图3. PG standby模式和apply日志过程

[PG]: /images/20220709/8ebeb07779cc44fbb28a3a14dfd7f2d4.png
[PG 1]: /images/20220709/77d6f92a83794642bce2d6736403d30d.png
[PG rstandby_apply]: /images/20220709/baace10f91a745dc96f3e27788fd2148.png