数据库内核月报 - 2015 / 10-PgSQL · 特性分析 · PG主备流复制机制

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主备总体框架图:


图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。


图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。


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

时间: 2024-10-25 20:22:22

数据库内核月报 - 2015 / 10-PgSQL · 特性分析 · PG主备流复制机制的相关文章

MySQL内核月报 2015.01-MySQL · 捉虫动态· 设置 gtid_purged 破坏AUTO_POSITION复制协议

bug描述 Oracle 最新发布的版本 5.6.22 中有这样一个关于GTID的bugfix,在主备场景下,如果我们在主库上 SET GLOBAL GTID_PURGED = "some_gtid_set",并且 some_gtid_set 中包含了备库还没复制的事务,这个时候如果备库接上主库的话,预期结果是主库返回错误,IO线程挂掉的,但是实际上,在这种场景下主库并不报错,只是默默的把自己 binlog 中包含的gtid事务发给备库.这个bug的造成的结果是看起来复制正常,没有错误

MySQL内核月报 2015.01-MySQL · 新增特性· DDL fast fail

背景 项目的快速迭代开发和在线业务需要保持持续可用的要求,导致MySQL的ddl变成了DBA很头疼的事情,而且经常导致故障发生.本篇介绍RDS分支上做的一个功能改进,DDL fast fail.主要解决:DDL操作因为无法获取MDL排它锁,进入等待队列的时候,阻塞了应用所有的读写请求问题. MDL锁机制介绍 首先介绍一下MDL(METADATA LOCK)锁机制,MySQL为了保证表结构的完整性和一致性,对表的所有访问都需要获得相应级别的MDL锁,比如以下场景: session 1对t1表做查询

阿里数据库内核月报:2016年11月

# 01 PgSQL · 特性分析 · 金融级同步多副本分级配置方法 # 02 MySQL · myrocks · myrocks之事务处理 # 03 MySQL · TokuDB · rbtree block allocator # 04 MySQL · 引擎特性 · Column Compression浅析 # 05 MySQL · 引擎介绍 · Sphinx源码剖析(一) # 06 PgSQL · 特性分析 · PostgreSQL 9.6 如何把你的机器掏空 # 07 PgSQL · 特

PgSQL · 特性分析 · 数据库崩溃恢复(上)

背景 为了合并I/O提高性能,PostgreSQL数据库引入了共享缓冲区,当数据库非正常关闭,比如服务器断电时,共享缓冲区即内存中的数据就会丢失,这个时候数据库操作系统重启时就需要从非正常状态中恢复过来,继续提供服务.本文将具体分析在这种情况下,PostgreSQL数据库如何从崩溃状态中恢复. 上期月报PgSQL · 特性分析 · checkpoint机制浅析中介绍了PostgreSQL中的checkpoint机制.其中提到,当PostgreSQL数据库崩溃恢复时,会以最近的checkpoint

阿里数据库内核月报:2015年11月

# 01 MySQL · 社区见闻 · OOW 2015 总结 MySQL 篇 # 02 MySQL · 特性分析 · Statement Digest # 03 PgSQL · 答疑解惑 · PostgreSQL 用户组权限管理 # 04 MySQL · 特性分析 · MDL 实现分析 # 05 PgSQL · 特性分析 · full page write 机制 # 06 MySQL · 捉虫动态 · MySQL 外键异常分析 # 07 MySQL · 答疑解惑 · MySQL 优化器 ran

PgSQL · 特性分析 · 数据库崩溃恢复(下)

背景 在上期月报PgSQL · 特性分析 · 数据库崩溃恢复(上),我们分析了PostgreSQL在数据库非正常退出后(包括通过recovery.conf用户主动恢复)的处理,概括起来分为以下几步: 1.如果满足以下条件之一,则进行非正常退出恢复 pg_control文件中的数据库状态不正常(非DB_SHUTDOWNED) pg_control文件中记录的最新检查点读取不到XLOG日志文件 2.用户指定recovery.conf文件主动恢复3.根据pg_control.backup_label确

阿里数据库内核月报:2017年10月

#01 PgSQL · 特性分析 · MVCC机制浅析 #02 MySQL · 性能优化· CloudDBA SQL优化建议之统计信息获取 #03 MySQL · 引擎特性 · InnoDB mini transation #04 MySQL · 特性介绍 · 一些流行引擎存储格式简介 #05 MSSQL · 架构分析 · 从SQL Server 2017发布看SQL Server架构的演变 #06 MySQL · 引擎介绍 · Sphinx源码剖析(三) #07 PgSQL · 内核开发 ·

阿里数据库内核月报:2015年07月

# 01 MySQL · 引擎特性 · Innodb change buffer介绍 # 02 MySQL · TokuDB · TokuDB Checkpoint机制 # 03 PgSQL · 特性分析 · 时间线解析 # 04 PgSQL · 功能分析 · PostGIS 在 O2O应用中的优势 # 05 MySQL · 引擎特性 · InnoDB index lock前世今生 # 06 MySQL · 社区动态 · MySQL内存分配支持NUMA # 07 MySQL · 答疑解惑 · 外

阿里数据库内核月报:2015年09月

# 01 MySQL · 引擎特性 · InnoDB Adaptive hash index介绍 # 02 PgSQL · 特性分析 · clog异步提交一致性.原子操作与fsync # 03 MySQL · 捉虫动态 · BUG 几例 # 04 PgSQL · 答疑解惑 · 诡异的函数返回值 # 05 MySQL · 捉虫动态 · 建表过程中crash造成重建表失败 # 06 PgSQL · 特性分析 · 谈谈checkpoint的调度 # 07 MySQL · 特性分析 · 5.6 并行复制