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

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: 背景 在上期月报PgSQL · 特性分析 · 数据库崩溃恢复(上),我们分析了PostgreSQL在数据库非正常退出后(包括通过recovery.conf用户主动恢复)的处理,概括起来分为以下几步: 1.

背景

在上期月报PgSQL · 特性分析 · 数据库崩溃恢复(上),我们分析了PostgreSQL在数据库非正常退出后(包括通过recovery.conf用户主动恢复)的处理,概括起来分为以下几步:

1.如果满足以下条件之一,则进行非正常退出恢复

  • pg_control文件中的数据库状态不正常(非DB_SHUTDOWNED)
  • pg_control文件中记录的最新检查点读取不到XLOG日志文件

2.用户指定recovery.conf文件主动恢复
3.根据pg_control、backup_label确定恢复的XLOG日志记录起点
不断读取每个XLOG record,根据所属的资源管理器去调用各自:

  • rm_startup()
  • rm_redo(EndRecPtr, record)
  • rm_cleanup();

4.不断恢复XLOG日志记录,直到满足以下条件之一,则停止恢复正常启动

  • 达到recovery.conf文件中规定的最终的目标恢复位点
  • 当前XLOG日志全部应用完成

5.清理环境,并启动需要的辅助进程
其中,PostgreSQL会根据每个XLOG record所属的资源管理器操作来执行对应的函数。PostgreSQL中有以下的资源管理器:

RM_XLOG_ID
RM_XACT_ID
RM_SMGR_ID
RM_CLOG_ID
RM_DBASE_ID
RM_TBLSPC_ID
RM_MULTIXACT_ID
RM_RELMAP_ID
RM_STANDBY_ID
RM_HEAP2_ID
RM_HEAP_ID
RM_BTREE_ID
RM_HASH_ID
RM_GIN_ID
RM_GIST_ID
RM_SEQ_ID
RM_SPGIST_ID

而每种资源管理器,都存在几种具体的操作,例如RM_HEAP_ID包括以下操作(后面的数字代表对应XLogRecord中xl_info字段高4位,详情参考上期月报):

#define XLOG_HEAP_INSERT        0x00
#define XLOG_HEAP_DELETE        0x10
#define XLOG_HEAP_UPDATE        0x20
/* 0x030 is free, was XLOG_HEAP_MOVE */
#define XLOG_HEAP_HOT_UPDATE    0x40
#define XLOG_HEAP_NEWPAGE        0x50
#define XLOG_HEAP_LOCK            0x60
#define XLOG_HEAP_INPLACE        0x70

下面我们将以堆表的INSERT操作为例,具体分析对应的XLOG record内容和资源管理器对应的处理函数。
**XLOG record
XLOG record 结构**
在PgSQL · 特性分析 · 数据库崩溃恢复(上)中,分析了WAL日志页的基本结构。其中,一条日志记录的的组织形式如下所示(以下分析基于RDS for PostgreSQL,即9.4版本):

*        Fixed-size header (XLogRecord struct) /*日志记录头*/
 *        rmgr-specific data /*资源管理器数据,对应操作的对象,譬如元组的id等内容*/
 *        BkpBlock/*备份块块头*/
 *        backup block data/*操作的一些数据,如更新元组时,要更新的新值存储在这个区域*/
 *        BkpBlock
 *        backup block data
 *        ...

为了更好地探究堆表INSERT操作对应XLOG record 的内容,我们创建一个简单的TABLE,并执行INSERT操作:

create table test(id int);
insert into test values(3);

XLogInsert函数
在执行INSERT操作的时候,PostgreSQL会调用heap_insert函数,其中会调用XLogInsert去插入对应的XLOG record:

recptr = XLogInsert(RM_HEAP_ID, info, rdata);
PageSetLSN(page, recptr);

注意:实际上是调用两次XLogInsert,除了HEAP INSERT操作的XLOG record,还有事务提交的XLOG record。

函数XLogInsert的返回值是XLogRecPtr结构类型,即LSN(log secquence number)。heap_insert函数在执行XLogInsert()后,把其返回值XLogRecPtr记录赋值给对应的page的PageHeaderData结构中,以实现WAL机制(参考PgSQL · 特性分析 · Write-Ahead Logging机制浅析)。

XLogInsert函数中会去包装一个XLOG record,并把它刷写到磁盘,我们接下来分析一下XLogInsert函数。

XLogInsert函数定义:

XLogRecPtr XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)

XLogInsert的三个函数参数分别是:

  • rmid
    1.RmgrId类型

2.代表本条XLOG record所属的资源管理器类型,例如我们上面的例子中INSERT操作属于RM_HEAP_ID,即堆表资源管理器

  • info
    1.uint8类型

2.代表资源管理器对应的操作,例如堆表中INSERT操作为0x00

  • rdata
    1.XLogRecData指针类型(链表)

2.每个XLogRecData结构体存储对应的资源管理器数据rmgr-specific data

之所以要用XLogRecData链,是因为在所要处理的日志记录实体数据在内存空间可能不是连续存储的,而且数据可能分布在多个缓冲区内,需要用XlogRecData链表将它们组织起来。XlogRecData数据结构如下:

typedef struct XLogRecData
{
    char       *data;    /*包含实体数据的起始位置*/
    uint32        len;        /*包含实体数据大小*/
    Buffer        buffer;    /*如果有buffer指明第几个缓冲区*/
    bool        buffer_std;    /*是否含有标准的pd_lower/pd_upper结构*/
    struct XLogRecData *next;    /*指向下一个XLogRecData*/
} XLogRecData;

其中,buffer_std该值为true,则容许XLOG释放备份页的空闲空间,空闲空间由pd_lower和pd_upper限定:

  • pd_lower表示页面起始位置与未分配空间开头的字节偏移
  • pd_upper表示页面末尾位置与未分配空间末尾的字节偏移
    通过分析三个XLogInsert函数参数,可以看出XLogInsert主要是将rdata封装成一个XLOG record。接下来我们将分析heap_insert函数内如何对rdata进行赋值。

heap_insert函数

heap_insert函数主要操作HeapTupleData结构体,对应在每个数据页中存储的每个tuple,结构如下图所示:

13


tuple分为头部信息和数据信息,这里不再展开,我们将在分析PostgreSQL的MVCC机制时,将其中的结构详细分析。

heap_insert函数的主要操作如下:

  • 调用RelationGetBufferForTuple方法找到shmem里缓存数据块buffer
  • 调用RelationPutHeapTuple方法,把组装好的元组tuple放到对应buffer中合适的位置
  • 赋值XLogRecData类型变量rdata,通过代码分析可以看出rdata实际上是对tuple的内容摘要
  • XLogRecData rdata[4]; 堆表的INSERT操作有4个XLogRecData结构体组成的链表
  • rdata[0].data 存储一个xl_heap_insert结构,用于标示一些基本信息:
/* This is what we need to know about insert */
typedef struct xl_heap_insert
{
    xl_heaptid    target;            /* inserted tuple id */
    uint8        flags;
    /* xl_heap_header & TUPLE DATA FOLLOWS AT END OF STRUCT */
} xl_heap_insert;
  • rdata[0].buffer = InvalidBuffer
  • rdata[1].data存储一个xl_heap_header结构,存储tuple头部的简化信息:
typedef struct xl_heap_header
{
    uint16        t_infomask2;
    uint16        t_infomask;
    uint8        t_hoff;
} xl_heap_header;
  • rdata[1].buffer = need_tuple_data ? InvalidBuffer : buffer;如果需要存储整个数据块,则把buffer赋值给rdata
  • rdata[2].data存储tuple头部后面的数据,比如INSERT操作的插入元组的每列的数值
  • rdata[2].buffer = need_tuple_data ? InvalidBuffer : buffer;同rdata[1]
  • 如果需要存储整个数据块,则rdata[3].buffer=buffer
  • 调用XLogInsert,将rdata封装成XLOG record写入WAL缓冲区,如果需要切换日志段文件,调用XLogWrite刷写到磁盘

经过以上分析,我们可以知道,XLOG record的核心部分是资源管理器数据(XLogRecData)和备份数据块(backup block data),这两个数据包含了我们恢复时候需要的数据。在各个资源管理器的具体操作调用XLogInsert之前,需要对这两个部分进行填充。

资源管理器对应处理函数

资源管理器结构

在恢复过程中,每个资源管理器对应的处理函数是不同的,为了更好的抽象资源管理器,在PostgreSQL中定义了RmgrData结构体和一个RmgrData类型数组RmgrTable。

typedef struct RmgrData
{
    const char *rm_name;
    void        (*rm_redo) (XLogRecPtr lsn, struct XLogRecord *rptr);
    void        (*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
    void        (*rm_startup) (void);
    void        (*rm_cleanup) (void);
} RmgrData;
extern const RmgrData RmgrTable[];
PG_RMGR(RM_XLOG_ID, "XLOG", xlog_redo, xlog_desc, NULL, NULL)
PG_RMGR(RM_XACT_ID, "Transaction", xact_redo, xact_desc, NULL, NULL)
PG_RMGR(RM_SMGR_ID, "Storage", smgr_redo, smgr_desc, NULL, NULL)
PG_RMGR(RM_CLOG_ID, "CLOG", clog_redo, clog_desc, NULL, NULL)
PG_RMGR(RM_DBASE_ID, "Database", dbase_redo, dbase_desc, NULL, NULL)
PG_RMGR(RM_TBLSPC_ID, "Tablespace", tblspc_redo, tblspc_desc, NULL, NULL)
PG_RMGR(RM_MULTIXACT_ID, "MultiXact", multixact_redo, multixact_desc, NULL, NULL)
PG_RMGR(RM_RELMAP_ID, "RelMap", relmap_redo, relmap_desc, NULL, NULL)
PG_RMGR(RM_STANDBY_ID, "Standby", standby_redo, standby_desc, NULL, NULL)
PG_RMGR(RM_HEAP2_ID, "Heap2", heap2_redo, heap2_desc, NULL, NULL)
PG_RMGR(RM_HEAP_ID, "Heap", heap_redo, heap_desc, NULL, NULL)
PG_RMGR(RM_BTREE_ID, "Btree", btree_redo, btree_desc, NULL, NULL)
PG_RMGR(RM_HASH_ID, "Hash", hash_redo, hash_desc, NULL, NULL)
PG_RMGR(RM_GIN_ID, "Gin", gin_redo, gin_desc, gin_xlog_startup, gin_xlog_cleanup)
PG_RMGR(RM_GIST_ID, "Gist", gist_redo, gist_desc, gist_xlog_startup, gist_xlog_cleanup)
PG_RMGR(RM_SEQ_ID, "Sequence", seq_redo, seq_desc, NULL, NULL)
PG_RMGR(RM_SPGIST_ID, "SPGist", spg_redo, spg_desc, spg_xlog_startup, spg_xlog_cleanup)
  • RmgrTable的下标对应上文提到的资源管理器ID,比如HEAP表对应的RmgrData是RmgrTable[RM_HEAP_ID]。
  • RmgrData中定义了rm_redo、rm_desc、rm_startup、rm_cleanup四个函数指针,分别对应每个资源管理器具体的redo、desc、startup、cleanup函数,我们主要分析下其中的rm_redo恢复函数

REDO函数

不同资源管理器的REDO函数参数都为(XLogRecPtr lsn, XLogRecord *record),这两个类型的参数我们在前面两期月报中均有涉及。其中:

  • XLogRecPtr类型代表着该log record在日志序列中的位置
  • XLogRecord类型代表着该log record的头部信息

REDO函数主要是根据该log record的位置取到对应的log record进行相应的恢复操作,下面我们以堆表INSERT操作为例,分析下对应的REDO函数heap_xlog_insert:

  • 调用XLogRecGetData(record)方法,取出上文中的xl_heap_insert结构xlrec
  • 如果该XLOG record存在full-page image,则恢复该数据块
  • 将上文提到的rdata恢复成tuple,写入到缓存数据块中
  • 标记缓存数据块为脏页,等待刷出

通过以上分析,我们可以大体知道XLOG record满足了以下几点才能实现崩溃恢复甚至是任意时间点恢复:

  • 可靠性
    1.full-page image,每次checkpoint第一次更新时都需要将整页复制

2.CRC32校验码
3.插入XLOG record时不接受其他信号

  • 可重复性
    1.多次重放一个log record,得到的结果相同
  • 可恢复性
    1.大多数资源管理器操作对应的log record中存储的都是对应数据在磁盘存储的一个摘要(例如INSERT操作的rdata是tuple的一个摘要)

XLOG日志在PostgreSQL运维中占据了非常重要的地位,从WAL机制到备份恢复以及主备复制,许多功能都离不开XLOG日志。推荐大家看下《PostgreSQL Replication》这本书,加深对PostgreSQL中XLOG以及Replication的理解。

另外,PostgreSQL XLOG目前也存在一些问题,最明显的问题就是写放大,因为full-page image导致XLOG record体积太大,如果设置不合理,可能日志的体积是数据体积的20倍左右。但是经过参数调优,可以尽可能地避免这种情况,可参考文章如何遏制PostgreSQL WAL的疯狂增长。

相关文章
|
3月前
|
关系型数据库 MySQL 分布式数据库
PolarDB 与传统数据库的性能对比分析
【8月更文第27天】随着云计算技术的发展,越来越多的企业开始将数据管理和存储迁移到云端。阿里云的 PolarDB 作为一款兼容 MySQL 和 PostgreSQL 的关系型数据库服务,提供了高性能、高可用和弹性伸缩的能力。本文将从不同角度对比 PolarDB 与本地部署的传统数据库(如 MySQL、PostgreSQL)在性能上的差异。
181 1
|
24天前
|
SQL 关系型数据库 MySQL
Vanna使用ollama分析本地数据库
这篇文章详细介绍了如何使用Vanna和Ollama框架来分析本地数据库,实现自然语言查询转换为SQL语句并与数据库交互的过程。
81 7
Vanna使用ollama分析本地数据库
|
24天前
|
存储 分布式计算 数据库
阿里云国际版设置数据库云分析工作负载的 ClickHouse 版
阿里云国际版设置数据库云分析工作负载的 ClickHouse 版
|
24天前
|
SQL 自然语言处理 关系型数据库
Vanna使用ollama分析本地MySQL数据库
这篇文章详细介绍了如何使用Vanna结合Ollama框架来分析本地MySQL数据库,实现自然语言查询功能,包括环境搭建和配置流程。
124 0
|
2月前
|
Oracle NoSQL 关系型数据库
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
198 2
|
2月前
|
SQL Java OLAP
Hologres 入门:实时分析数据库的新选择
【9月更文第1天】在大数据和实时计算领域,数据仓库和分析型数据库的需求日益增长。随着业务对数据实时性要求的提高,传统的批处理架构已经难以满足现代应用的需求。阿里云推出的 Hologres 就是为了解决这个问题而生的一款实时分析数据库。本文将带你深入了解 Hologres 的基本概念、优势,并通过示例代码展示如何使用 Hologres 进行数据处理。
266 2
|
3月前
|
网络协议 NoSQL 网络安全
【Azure 应用服务】由Web App“无法连接数据库”而逐步分析到解析内网地址的办法(SQL和Redis开启private endpoint,只能通过内网访问,无法从公网访问的情况下)
【Azure 应用服务】由Web App“无法连接数据库”而逐步分析到解析内网地址的办法(SQL和Redis开启private endpoint,只能通过内网访问,无法从公网访问的情况下)
|
16天前
|
存储 关系型数据库 MySQL
Mysql(4)—数据库索引
数据库索引是用于提高数据检索效率的数据结构,类似于书籍中的索引。它允许用户快速找到数据,而无需扫描整个表。MySQL中的索引可以显著提升查询速度,使数据库操作更加高效。索引的发展经历了从无索引、简单索引到B-树、哈希索引、位图索引、全文索引等多个阶段。
50 3
Mysql(4)—数据库索引
|
1天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
19 2
|
4天前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
20 4