如何用好PostgreSQL的备份与恢复?

前端之家收集整理的这篇文章主要介绍了如何用好PostgreSQL的备份与恢复?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

点击有惊喜


如何用好Postgresql的备份与恢复?

作者

赵成

日期

2017-10-22

标签

Postgresql,数据库高可用 , 备份与恢复


高可用性是数据库的关键指标,简单说就是要做到故障时间短,数据不丢失,能够回退到指定位置(时间/事务)。实现高可用的基础是数据库的备份与恢复技术。

Postgresql备份与恢复操作涉及的参数和相关文件较多,内部逻辑关系较复杂,恢复分类方式容易混淆,这些都会影响到Postgresql高可用方案的实现。

本文首先介绍通常的数据库故障场景与处理方案,然后通过梳理Postgresql数据库备份与恢复的相关文件、参数配置与主要流程,对Postgresql恢复方式进行了清晰分类,最后给出了应对典型故障,Postgresql备份与恢复的配置方案。

一、故障场景和处理方案

数据库采用数据文件加日志文件,两份数据的存储方式。为提高性能数据库运行时操作的数据位于内存缓冲区,缓冲区的数据延迟写入数据文件,因此数据文件会处于不一致的状态。数据的变更记录称为日志记录,日志记录以日志文件方式存储在磁盘上。日志记录也是先写入日志缓冲区,再写入日志文件。通过两个简单的规则Write-ahead log(将数据写入数据文件前,先将对应的日志记录写入日志文件)和Force log at commit(事务提交时,将其所有日志记录写入日志文件),可以保证通过日志文件完整的恢复数据文件

传统的故障类型包括事务内部故障、系统故障、介质(磁盘)故障。对于事务内部故障和系统故障,数据库使用日志文件自动恢复,不需要人工干预。为应对介质故障,DBA需事先备份数据,发生故障后,使用备份数据恢复数据库

可靠的磁盘设备可以大幅降低介质故障概率,但不能减少数据备份工作。一个常见的故障是数据误操作,即修改了不应该修改的数据。从数据库的角度看,误操作是正常的操作,不会进行自动恢复,只有使用备份数据才能恢复。同时,提供一段时间内历史数据的访问,也是一个常见的需求。

数据的备份与恢复可以分为逻辑与物理两种方式。

  • 逻辑备份与恢复:备份时,使用工具将数据全量导出为外部文件,恢复时,使用工具,将备份文件导入新建的数据库

  • 物理备份与恢复:备份时,配置实例处于归档模式,将生成的日志文件保持到指定位置。使用热备工具直接拷贝数据的数据目录,作为基线数据。恢复时,使用基线数据和日志文件将数据恢复到一致的状态。
    逻辑方式不支持增量方式,适用于数据较小情况下的备份与恢复。物理方式支持增量备份,适合大数据量的备份与恢复。本文只讨论物理备份与恢复,下图为物理备份与恢复的基本流程。

在高可用需求中,当单台实例发生故障,需要快速提供备用实例。备份基线数据+日志文件的方式无法满足时间要求。通常采用主备(master/slave)方案,master与slave通过日志流复制进行同步,slave可以提供只读数据访问,当master发送故障后,直接将应用请求转发到slave。

在高可用方案中,需要支持介质故障恢复,实时故障切换,误操作数据恢复,查看历史数据等功能。流复制技术和物理备份与恢复的结合,可以满足数据库高可用的基本要求。

流复制 物理备份与恢复
介质故障恢复 支持 支持
实时故障切换 不支持
误操作数据恢复 不支持 查看历史数据 支持

Postgresql备份与恢复相关文件、参数配置与主要流程

Postgresql日志文件的命名

日志序号 (lsn:log sequence number) 标识日志记录在日志文件中的位置。lsn是一个64位的整数。Postgresql运行时生成的日志文件存放在数据目录下的pg_xlog目录,每个日志文件称为一个segment,日志文件大小固定,由wal_segment_size参数指定,日志文件内部划分为多个wal page,每个page的大小由wal_block_size参数指定。

对于一个64位的lsn,可以计算出其所在的xlog文件名。lsn可以划分segment序号高位,segment序号低位和块内序号三个部分。对于segment大小为64M和16M的情况如下:

16M:segment序号高位(32比特)+segment序号低位(8比特)+块内序号(24比特)

64M:segment序号高位(32比特)+segment序号低位(6比特)+块内序号(26比特)

Xlog文件名由三部分组成,格式为:时间线+segment序号高位+segment序号低位,每个部分都表示为一个8位16进制数字。取出lsn中的segment高位和segment低位数值,就可以确定其所在的xlog文件

使用pg_current_xlog_location()查询当前lsn为0/1C000090(16进制高32位/16进制低32位),当前时间线为1,wal segment大小为64M,

根据64M大小日志文件名格式,可计算出lsn的segment序号高32位为0x0,segment序号低位为0x7, 块内序号为0x90,xlog文件名为000000010000000000000007
使用pg_xlogfile_name_offset()可以查询lsn对应的文件文件内偏移,与上述计算一致。

checkpoint与control文件

Postgresql的数据文件和日志文件互为冗余。当某lsn之前的操作已经全部写入了数据文件后,则该lsn号之前的日志文件可以丢弃。checkpoint机制实现此功能

checkpoint操作在以下场景执行:管理员手工执行check命令、数据库启动完成恢复、数据库正常关闭,以及后台Checkpoint进程的定期执行。

checkpoint流程可以简单描述为,首先构造checkpoint记录(redo字段为当前已写入日志文件的lsn),然后将数据缓冲区中的脏数据写入磁盘,最后写入checkepoint日志记录(包含checkpoint记录),并将checkpoint记录写入control文件

512字节的control文件是Postgresql的关键数据,用于数据库启动时,判断数据库状态和恢复位置。controlfile文件中记录了数据库的状态,最近checkpoint记录,最小恢复lsn信息和基本的参数配置。数据库的状态包括

  • DB_SHUTDOWNED(数据库正常关闭
  • DB_SHUTDOWNED_IN_RECOVERY(数据库在恢复时关闭
  • DB_SHUTDOWNING(数据库启动到正常关闭过程中崩溃)
  • DB_IN_CRASH_RECOVERY(数据库在恢复过程中崩溃),
  • DB_IN_ARCHIVE_RECOVERY(数据库处于归档恢复)
  • DB_IN_PRODUCTION(数据库处于正常工作状态,等待接受事务处理)

日志文件生成与归档

Postgresql日志文件的segment序号从1开始,一个日志文件写完后,会写入下一个序号的日志文件。checkpoint之后,最近一次checkpoint.redo lsn之前的日志文件可以丢弃。Postgresql会循环使用日志文件。checkpoint操作中,会将可丢弃的日志文件改名为未来的日志文件名,并该日志文件重新初始化。Postgresql在写新的日志文件时,如果该文件已存在,则使用该文件,否则才会创建新的文件。因此不能从pg_xlog目录中的文件名直接判断当前的日志文件,需要使用pg_current_xlog_location和pg_xlogfile_name_offset函数进行判断。

为持久保存日志文件,需要开启日志归档模式。在该模式下,可丢弃日志文件删除前,被拷贝到指定目录。在postgres.conf配置文件中设置三个参数:

wal_level=replica 或更高
archive_mode = on
archive_command = 'cp %p /mnt/server/archivedir/%f'
%p表示pg_xlog目录路径和日志文件名,%f表示日志文件名。 日志被拷贝到/mnt/server/archivedir目录

日志的归档过程如下:

  • checkpoint操作中,当一个日志文件X可丢弃时,在pg_xlog的archive_status目中生成X.ready文件
  • 后台archive进程负责日志文件的拷贝。该进程监控archive_status目录,当发现有X.ready文件名后,使用archive_command拷贝文件,并将X.ready命名为X.done
  • 下一次checkpoint操作中,将archive_status目中X.done对应的X日志文件改名。

crash recovery

Postgresql正常运行中,直接kill主进程,重启Postgresql,将进入crash recovery处理流程,从control文件中checkpoint的redo lsn位置开始,
使用pg_xlog目录中的日志文件进行恢复。Postgresql能进行上述处理,是因为将其状态和最近的checkpoint记录在在control文件中。

初始化数据库后,control文件DB状态初始值为shutdown。pg启动时,当control文件DB状态为shutdown,则将状态设置为production,退出恢复过程。在正常关闭服务时,执行checkpoint,并将control文件DB状态设置shutdown。pg启动时,当control文件DB状态为production,则说明发生了crash,会从control文件读取最近checkpoint,从redo lsn开始进行恢复,恢复完成后,将状态设置为production。

热备

备份分为冷备和热备。冷备是正常关闭服务后拷贝文件。热备是服务正常运行中拷贝文件。由于采用数据缓冲区机制,拷贝的文件数据会不一致。根据数据库恢复基本原理,只要确定某lsn之前的日志已经全部写入了数据文件,则在拷贝后的数据文件上,应用该lsn号之后的日志文件,可将数据恢复到一致的状态。

热备包括以下步骤

  • 执行pg_start_backup函数:该函数执行checkpoint,将checkpont信息写入数据目录下的backup_label文件
  • 拷贝数据目录到指定位置
  • 执行pg_stop_backup函数:该命令删除backup_label文件,写XLOG_BACKUP_END日志,并在pg_xlog目录中写入backup文件,该文件记录了热备开始和结束的lsn信息。

backup文件格式为:热备开始lsn对应的日志文件名.开始lsn的块内偏移.backup

使用归档日志恢复

Crash recovery只能使用pg_log目录中的日志文件进行恢复,启用archive recovery模式后,可以使用其它目录的日志文件(归档日志文件)进行恢复。

在数据目录存创建recover.conf文件,Postgresql启动时,读取到该文件,会进入archive recovery流程。在recover.conf中设置日志拷贝命令restore_command,pg恢复过程中,使用该命令将归档日志拷贝到pg_xlog目录后进行恢复。

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
%f表示日志文件%p表示目标路径和文件

使用流复制恢复

流复制可以视为archive recovery的一种情况。使用归档日志文件进行恢复时,备机需要获取主机一个完整xlog文件,才可进行恢复。在流复制中,主机产生日志记录后,会及时发送到备机。

在slave节点数据目录的recover.conf中,配置到主机的连接信息primary_conninfo并设置standby_mode为on。

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

master节点的postgres.conf文件中指定wal_level和发送日志进程的数目max_wal_senders。

wal_level=replica 或更高
max_wal_senders=5

在master的pg_hba.conf文件中允许复制连接建立

host    replication     postgres        192.168.10.0/24            trust

slave启动后会启动wal reciver进程,根据primary_conninfo向master发送连接请求。master收到请求后,启动wal sender进程,wal sender与reciver建立连接。 wal reciver将起始的lsn信息发送给wal sender,wal sender从该lsn开始,将日志记录持续发送给wal reciver,wal reciver将日志写入pg_xlog目录中的日志文件,并通知恢复进程读取文件进行恢复处理。

恢复的退出与时间线

Crash recovery模式下,应用完pg_xlog目录中的所有可用日志文件后,自动退出恢复,进入运行状态。Archive recovery模式下,recovery.conf文件中参数standby_mode为off时,应用完所有日志后,自动退出恢复,进入运行状态。standby_mode为on时,应用完所有日志后,恢复流程不会退出,持续读取可用日志(来自于归档日志文件或流复制),当收到pg_ctl工具发出的promote命令后,才退出恢复流程,进入运行状态。

可以通过设置Recovery Target,使得archive recovery在指定的位置(时间或事务号)停止恢复。在recovery.conf文件配置如下参数,表示恢复流程在恢复完123947事务后结束。

recovery_target_xid = '123947'

时间线(Timeline)是Postgresql中的特有的概念。其初始值为1,退出archive recovery时,timeline增1,退出crash recovery时,timeline不变。Timeline反映在日志的文件名中,日志文件的命名格式为:时间线号+segment序号高位+segment序号低位。

引入时间线概念后,日志位置的唯一标识从lsn变为时间线+lsn,checkpoint的结构中记录了当前的timeline。

发生时间线切换时,在pg_xlog目录写入时间线history文件文件名为"当前timelime.history",文件内记录了时间线切换的历史纪录,每一行记录一条时间线信息,格式为。

parentTLI为时间线id,为切换发生后的lsn,为发生切换的原因。

从时间线history文件中,可以计算出每条时间线的开始和结束lsn。

时间线文件00000003.history,内容1   0/14000060  no recovery target specified
2   140420D0  no recovery target specified

文件含义为当前时间线为3,时间线1的lsn范围[0/0,0/14000060),
时间线2的lsn范围[0/14000060,0/140420D0),时间线3从0/140420D0开始。

使用timeline有以下优点:

  • 切换逻辑显得清晰。从时间线history文件,可以计算出每条时间线的开始和结束lsn。
  • 避免归档日志的覆盖。当备机与主机的归档目录相同时,备机升级为主机后,生成的日志文件名与原主机不同(时间线不同),拷贝到归档目录后,不会覆盖之前的日志文件

点击有惊喜

猜你在找的Postgre SQL相关文章