Postgresql之从崩溃状态中恢复
|
wal_level：
控制wal存储的级别。wal_level决定有多少信息被写入到WAL中。 默认值是最小的（minimal），其中只写入从崩溃或立即关机中恢复的所需信息。replica 增加 wal 归档信息 同时包括 只读服务器需要的信息。（9.6 中新增，将之前版本的 archive 和 hot_standby 合并） logical 主要用于logical decoding 场景 推测：只记录最新的checkpoin时间点之后的wal log,当产生一个新的checkpoint后，该checkpoint时间点之前的wal log可以清掉。 为了合并I/O提高性能，PostgreSQL数据库引入了共享缓冲区，当数据库非正常关闭，比如服务器断电时，共享缓冲区即内存中的数据就会丢失，这个时候数据库操作系统重启时就需要从非正常状态中恢复过来，继续提供服务。本文将具体分析在这种情况下，PostgreSQL数据库如何从崩溃状态中恢复。 上期月报PgSQL · 特性分析 · checkpoint机制浅析中介绍了PostgreSQL中的checkpoint机制。其中提到，当PostgreSQL数据库崩溃恢复时，会以最近的checkpoint为基础，不断应用这之后的XLOG日志。为了更好地理解PostgreSQL数据库从崩溃中恢复的过程，我们需要弄清楚以下几个问题：
数据库状态在PostgreSQL中，把数据库分为以下几种状态： typedef enum DBState
{
DB_STARTUP = 0,/*数据库启动*/
DB_SHUTDOWNED,94);">/*数据库正常关闭*/
DB_SHUTDOWNED_IN_RECOVERY,94);">/*数据库在恢复时关闭*/
DB_SHUTDOWNING,94);">/*数据库启动到正常关闭过程中崩溃*/
DB_IN_CRASH_RECOVERY,94);">/*数据库在恢复过程中崩溃*/
DB_IN_ARCHIVE_RECOVERY,94);">/*数据库处于归档恢复*/
DB_IN_PRODUCTION/*数据库处于正常工作状态，等待接受事务处理*/
} DBState;
PostgreSQL的数据库状态被存储在pg_control文件中，可以执行pg_controldata命令，查看当前的数据库状态，返回结果如下： pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6403125794625722170
Database cluster state: shut down
...
其中 Database cluster state: shut down指明当前数据库的状态为DB_SHUTDOWNED，即正常关闭状态。 pg_control文件由对应的结构体ControlFileData存储，ControlFileData数据结构如下： struct ControlFileData
{
uint64 system_identifier; /*唯一系统标识符——保证控制文件和产生XLOG文件的数据库一致*/
uint32 pg_control_version; /* 标识pg_control的版本*/
uint32 catalog_version_no; /*标识catalog的版本 */
DBState state; /*最后一次操作后的数据库状态 */
pg_time_t time; /*pg_control最近一次更新的时间时*/
...
pg_crc32 crc;
} ControlFileData;
每次PostgreSQL数据库启动时，会读取pg_control文件获取最后一次操作后的数据库状态，如果为非正常关闭状态（DB_SHUTDOWNED），则会执行崩溃恢复逻辑。 checkpoint相关结构ControlFileData结构当数据库意识到自己处于崩溃状态后，会去选择一个合适的checkpoint作为基础，不断应用在这之后的XLOG日志。在PostgreSQL中，最近一次检查点的信息会被存储在pg_control文件中，pg_control由对应的结构体ControlFileData存储，ControlFileData数据结构如下： struct ControlFileData
{
...
XLogRecPtr checkPoint; /*指向最近一次的检查点位置*/
XLogRecPtr prevCheckPoint; /*指向最近一次检查点的前一次检查点的位置*/
CheckPoint checkPointCopy; /*最近一次检查点控制信息的副本*/
XLogRecPtr minRecoveryPoint; /*归档恢复时必须恢复到的最小LSN*/
XLogRecPtr backupStartPoint; /*在线备份时进行的检查点开始LSN*/
XLogRecPtr backupEndPoint; /*在线备份时进行的检查点结束LSN*/
bool backupEndRequired; /* 用于判断是否基于正确的在线备份集恢复*/
TimeLineID minRecoveryPointTLI; /* 必须恢复到的最小时间线 */
...
pg_crc32 crc;
} ControlFileData;
在数据库崩溃恢复过程中，一般会选取最近一次的检查点作为恢复的基础，但是因为一个检查点的时间比较长，所以有可能数据库系统在检查点做完之前崩溃，这样磁盘上的检查点可能是不完全的，所以PostgreSQL数据库会多存储一个检查点的位置，即prevCheckPoint。 在数据库崩溃恢复过程中，PostgreSQL规定了三个在启动之前必须恢复到的最小位点：
recovery.conf文件在恢复过程中，用户可以通过使用recovery.conf文件来指定恢复的各个参数，如下：
如果recovery.conf中同时指定了recoveryTargetXid、recoveryTargetName、recoveryTargetTime时，PostgreSQL会按照RECOVERY_TARGET_XID> RECOVERY_TARGET_NAME > RECOVERY_TARGET_TIME的优先级来获取最终的目标恢复位点。 如果在recovery.conf指定recovery_targetTimeLine为latest，则可以基于当前TimeLineID为起点寻找最新时间线：
XLOG日志结构XLOG日志中详细地记录了服务进程对数据库的操作过程。之前的月报PgSQL · 特性分析 · Write-Ahead Logging机制浅析介绍过PostgreSQL WAL机制的实现，下面将具体介绍XLOG日志的组织结构。 概括起来，XLOG日志分为多个XLOG逻辑日志文件，每个逻辑日志文件包含多个XLOG段文件，每个XLOG段文件包含多个XLOG日志页：
其中，值得注意的是，每个XLOG段文件大小可以在编译时使用–with-wal-segsize参数来指定，每页的大小可以在编译的时使用–with-wal-blocksize参数来指定，接下来主要介绍XLOG日志每页的组织形式。 XLOG日志页的组织形式在PostgreSQL中，XLOG日志页可以分为以下几部分：
XLOG日志页头部信息每个XLOG日志页分为页面头部信息和日志记录，其头部信息XLogPageHeaderData结构如下： struct XLogPageHeaderData
{
uint16 xlp_magic; /* 校验位，用于识别不同的XLOG版本 */
uint16 xlp_info; /* flag bits,see below */
TimeLineID xlp_tli; /* 页面第一条记录的时间线 */
XLogRecPtr xlp_pageaddr; /* XLOG页面的首地址 */
uint32 xlp_rem_len; /* 前XLOG页面最后一条记录剩余的长度 */
} XLogPageHeaderData;
其中，xlp_info是标志位：
如果当前的页面没有足够的空间来存储一个XLOG日志记录，系统允许将剩余的数据存储到下一个页面，但是XLog日志记录的头部信息，即后文中的XLogRecord是不允许分开存储到两个不同的页面的。 如果该页面为段文件的首个页面，除了上面的标准页面头部信息外，还增加一个长头部用来更精确地定位文件，即XLogLongPageHeaderData： struct XLogLongPageHeaderData
{
XLogPageHeaderData std; /* 标准页面头部信息 */
uint64 xlp_sysid; /* pg_control 中的系统标识符*/
uint32 xlp_seg_size; /* 段的尺寸 */
uint32 xlp_xlog_blcksz; /* 页（块）的尺寸*/
} XLogLongPageHeaderData;
#### XLOG日志记录的头部信息 每个XLOG日志页面头部之后才是真正的XLOG日志记录，XLogRecord记录了XLOG的相关数据信息，具体结构如下： struct XLogRecord
{
uint32 xl_tot_len; /* 整条记录的总长度*/
TransactionId xl_xid; /* 事务ID */
XLogRecPtr xl_prev; /* 上条XLOG日志记录的位置（LSN） */
uint8 xl_info; /* 资源管理器ID */
/* 2 bytes of padding here,initialize to zero */
pg_crc32c xl_crc; /* 本记录的CRC校验码 */
/* XLogRecordBlockHeaders and XLogRecordDataHeader follow,no padding */
} XLogRecord;
其中，xl_rmid表示资源管理器ID，在PostgreSQL中，资源管理器根据资源种类，可以分为17类，其分别的ID按照以下顺序分别为0-16： PG_RMGR(RM_XLOG_ID,"XLOG",xlog_redo,xlog_desc,NULL,255);">NULL)
PG_RMGR(RM_XACT_ID,116);">"Transaction",xact_redo,xact_desc,255);">NULL)
PG_RMGR(RM_SMGR_ID,116);">"Storage",smgr_redo,smgr_desc,255);">NULL)
PG_RMGR(RM_CLOG_ID,116);">"CLOG",clog_redo,clog_desc,255);">NULL)
PG_RMGR(RM_DBASE_ID,116);">"Database",dbase_redo,dbase_desc,255);">NULL)
PG_RMGR(RM_TBLSPC_ID,116);">"Tablespace",tblspc_redo,tblspc_desc,255);">NULL)
PG_RMGR(RM_MULTIXACT_ID,116);">"MultiXact",multixact_redo,multixact_desc,255);">NULL)
PG_RMGR(RM_RELMAP_ID,116);">"RelMap",relmap_redo,relmap_desc,255);">NULL)
PG_RMGR(RM_STANDBY_ID,116);">"Standby",standby_redo,standby_desc,255);">NULL)
PG_RMGR(RM_HEAP2_ID,116);">"Heap2",heap2_redo,heap2_desc,255);">NULL)
PG_RMGR(RM_HEAP_ID,116);">"Heap",heap_redo,heap_desc,255);">NULL)
PG_RMGR(RM_BTREE_ID,116);">"Btree",btree_redo,btree_desc,255);">NULL)
PG_RMGR(RM_HASH_ID,116);">"Hash",hash_redo,hash_desc,255);">NULL)
PG_RMGR(RM_GIN_ID,116);">"Gin",gin_redo,gin_desc,gin_xlog_startup,gin_xlog_cleanup)
PG_RMGR(RM_GIST_ID,116);">"Gist",gist_redo,gist_desc,gist_xlog_startup,gist_xlog_cleanup)
PG_RMGR(RM_SEQ_ID,116);">"Sequence",seq_redo,seq_desc,255);">NULL)
PG_RMGR(RM_SPGIST_ID,116);">"SPGist",spg_redo,spg_desc,spg_xlog_startup,spg_xlog_cleanup)
其中，上述引用代码中PG_RMGR函数的参数依次为：
在PostgreSQL中，用xl_rmid和xl_info高4位来唯一地标示该XLOG日志记录对应的数据库操作，例如事务资源管理器（RM_XACT_ID)，对应XLogRecord中xl_info字段高4位： #define XLOG_XACT_COMMIT 0x00
#define XLOG_XACT_PREPARE 0x10
#define XLOG_XACT_ABORT 0x20
#define XLOG_XACT_COMMIT_PREPARED 0x30
#define XLOG_XACT_ABORT_PREPARED 0x40
#define XLOG_XACT_ASSIGNMENT 0x50
#define XLOG_XACT_COMMIT_COMPACT 0x60
例如元组管理器(RM_HEAP_ID)，对应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
xl_info字段是个xl_info低4位表示当前XLOG记录数据块备份的情况： #define XLR_BKP_BLOCK_MASK 0x0F /* all info bits used for bkp blocks */
#define XLR_MAX_BKP_BLOCKS 4
#define XLR_BKP_BLOCK(iblk) (0x08 >> (iblk)) /* iblk in 0..3 */
当日志记录涉及到的缓冲区Buffer从上个checkpoint后第一次被修改，则将该Buffer备份附加到XLOG日志的备份块iblk中，对应修改xl_info的XLR_BKP_BLOCK(iblk)位。这是为了保证每个写入到磁盘的数据都是完整的页，当写入某个整页的过程中出现崩溃，即写入的页面不是完整的，则可以从XLOG日志中知直接将备份块恢复过来。 除此之外，XLogRecord的xl_crc记录XLOG日志记录的CRC校验，保证写入到磁盘的XLOG记录都是完整的，如果应用不完整的日志记录，PostgreSQL会报错。 XLOG日志记录的资源管理器数据XLOG日志记录的资源管理器数据由一系列XLogRecData结构体链表组成，之所以要用XLogRecData链，是因为在所要处理的日志记录实体数据在内存空间可能不是连续存储的，而且数据可能分布在多个缓冲区内，需要用XlogRecData链表将它们组织起来。XlogRecData数据结构如下： struct XLogRecData
{
char *data; /*资源管理器包含数据的开始*/
uint32 len; /*资源管理器包含的数据大小*/
Buffer buffer; /*如果有buffer指明第几个缓冲区*/
bool buffer_std; /*是否含有标准的pd_lower/pd_upper结构*/
struct XLogRecData *next; /*指向下一个结构体*/
} XLogRecData;
其中，buffer_std该值为true，则容许XLOG释放备份页的空闲空间，空闲空间由pd_lower和pd_upper限定：
XLogRecData中data保存每条XLOG日志记录中的数据信息，以INSERT、UPDATE、DELETE为例，XLogRecData中data的大体内容如下（该图引自《Internals Of PostgreSQL Wal》）： 可以看出，根据XLogRecData的信息，我们很容易恢复出对应的数据。 备份数据块备份数据块包含一个头部信息BkpBlock和一块大小的备份数据，其中BkpBlock结构如下： struct BkpBlock
{
RelFileNode node; /* 用于唯一标示该块所属的关系表，包括表空间OID，数据库OID，关系表OID等*/
ForkNumber fork; /*一个关系表在存储上可能由多个分支组成，每个分支以文件单独存储，RelFileNode对应关系表的分支号*/
BlockNumber block; /*对应块的块号*/
uint16 hole_offset; /*空洞偏移量*/
uint16 hole_length; /* 空洞长度*/
} BkpBlock;
如果需要备份的块存在空洞，则备份的时候只记录这个空洞的偏移量和长度，但没有实际备份它，从而提高备份效率。 备份数据块头部后紧跟一个块大小的备份数据，该块可以在数据库崩溃恢复时直接恢复。 Redo恢复的具体步骤每次postmaster进程启动时，都会调用StartupXLOG函数对数据库崩溃进行恢复，由于该过程非常繁琐，为了更好的理解，本文把Redo恢复分为三个阶段： Redo恢复前该阶段主要是根据数据库当前状态判断是否需要恢复，如果需要则获取恢复的起始位点以及目标恢复时间线（recoveryTargetTLI）；如不需要则正常启动系统。该阶段具体操作如下：
总结起来，在PostgreSQL中，如果启动时遇到以下情况，需要进行恢复操作：
其中第三种情况是用户通过配置文件recovery.conf手动控制恢复过程。 Redo恢复中上个阶段主要是做Redo恢复之前的准备工作，确定恢复起始的位置，而本阶段主要是基于上个阶段，进行真正的恢复操作：
Redo恢复后这个阶段主要是对Redo恢复的环境进行清理，并启动需要的辅助进程。
总结至此，我们分析了PostgreSQL数据库在崩溃时恢复的具体过程，其中具体的Redo恢复过程，实际上是通过资源管理器获取对应的redo函数接口来执行恢复操作，每种资源管理器其处理过程不尽相同，这里我们不再一一介绍。 ===================================================================================================== PostgreSQL在数据库非正常退出后（包括通过recovery.conf用户主动恢复）的处理，概括起来分为以下几步： 如果满足以下条件之一，则进行非正常退出恢复 pg_control文件中的数据库状态不正常（非DB_SHUTDOWNED） pg_control文件中记录的最新检查点读取不到XLOG日志文件 用户指定recovery.conf文件主动恢复 根据pg_control、backup_label确定恢复的XLOG日志记录起点 不断读取每个XLOG record，根据所属的资源管理器去调用各自： rm_startup() rm_redo(EndRecPtr,record) rm_cleanup(); 不断恢复XLOG日志记录，直到满足以下条件之一，则停止恢复正常启动 达到recovery.conf文件中规定的最终的目标恢复位点 当前XLOG日志全部应用完成 清理环境，并启动需要的辅助进程（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |