1.1 日志归档的目的

pg数据库日志归档是将PostgreSQL数据库的日志文件进行归档的过程。

归档的主要目的是为了保留历史数据,确保数据的一致性和完整性,同时为数据恢复提供必要的支持。

pg数据库日志归档的目的包括:

1.数据恢复:通过归档日志,可以在需要时回滚到任何时间点,从而进行数据的恢复。这是PITR(Point-In-Time Recovery)技术的基础,它允许数据库恢复到其运行历史中的任意一个有记录的时间点。
2.保证数据一致性:归档日志可以确保在数据库故障或其他中断时,所有已提交的事务都得到了持久保存。这确保了数据的完整性和一致性。
3.备份和恢复策略:通过定期归档日志,可以创建数据库的备份,并在需要时使用这些备份进行恢复。
4.监控和审计:归档日志还可以用于监控和审计数据库的活动,以便更好地了解数据的变动情况。
总之,pg数据库日志归档是确保数据库正常运行、保证数据一致性和完整性、实现数据恢复的重要手段。


1.2 启用归档模式

1.找到并编辑postgresql.conf文件。通常位于/etc/postgresql/版本号/main/目录下。
2.修改或添加以下设置:

wal_level = replica
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

3.保存并关闭文件。
4.重新启动PostgreSQL服务以应用更改:

Bash: systemctl restart postgresql

archive_command仅在已完成的 WAL 段上调用。因此,如果服务器只产生很少的 WAL 流量(或产生流量的周期很长),那么在事务完成和它被安全地记录到归档存储之间将有一个很长的延迟。为了限制未归档数据存在的时间,可以设置archive_timeout来强制服务器来周期性地切换到一个新的 WAL 段文件。 当这个参数被设置为大于零时,只要从上次段文件切换后过了参数所设置的时间量,并且已经有过任何数据库活动(包括一个单一检查点),服务器将切换到一个新的段文件(如果没有数据库活动则会跳过检查点)。
例如设置了archive_timeout=100后,PostgreSQL服务器会每隔100秒自动切换到新的WAL段文件。这意味着每隔100秒,一个新的WAL文件将被创建,并开始记录后续的更改。

需要注意的是,archive_timeout参数仅对已完成的WAL段进行切换。
如果数据库的写入量较少,或者在100秒内没有足够的活动导致WAL段完成,那么可能不会每个100秒生成一个新的WAL文件。
实际的切换时间可能会受到写入活动的变化和系统的负载的影响。


1.3 创建归档日志目录

如果尚未创建归档日志目录,则需要执行以下操作:
运行以下命令以创建目录:

Bash: mkdir -p /path/to/archive

还需要确保PostgreSQL进程具有写入该目录的权限。


1.4 验证归档设置

查看PostgreSQL的日志文件以验证是否已成功启用归档模式。Pg14日志文件位于/var/bin/pgsql/14/data/pg_wal目录下。检查日志以查找与归档模式相关的消息。如果一切正常,则可以看到有关已启用归档模式的消息。

WAL(Write-Ahead Logging)文件是PostgreSQL数据库中非常重要的日志文件,它记录了所有对数据库的更改。WAL文件的具体作用如下:

1.数据完整性:WAL确保了数据的完整性。在数据库发生故障时,可以通过使用WAL文件进行恢复,确保数据的完整性和一致性。
2.故障恢复:如果数据库发生故障,如系统崩溃或数据损坏,WAL文件可用于重新应用那些在故障发生时尚未写入数据文件的更改。这意味着即使数据文件已损坏,PostgreSQL也可以从WAL文件中检索数据,并恢复到一致的状态。
3.并发控制:WAL还支持并发控制,通过将数据更改记录在WAL中,可以确保多个事务并发执行时数据的完整性和一致性。
4.备份和恢复:WAL文件可以用于备份和恢复操作。通过定期备份WAL文件,可以在数据丢失的情况下进行恢复。
5.复制:WAL还支持数据库的流复制,允许将数据更改从一个数据库服务器复制到另一个数据库服务器。这对于高可用性和负载均衡场景非常有用。
总的来说,WAL文件在PostgreSQL中起着至关重要的作用,确保了数据的完整性、可靠性和并发性。


1.5 操作步骤

1、打开配置文件:

vi /var/bin/pgsql/14/data/postgresql.conf

查看pggresql日志 查看pg数据库日志位置_数据库


查看pggresql日志 查看pg数据库日志位置_hive_02


配置完archive_mode、archive_command、wal_level和fsync后保存配置文件。

2、重启pg数据库

systemctl restart postgresql-14.service

3、新建备份文件夹

mkdir –p /pg_base	#创建基础备份目录
mkdir –p /archive		#创建基础备份目录

4、在表中插入测试数据

create table test (id integer);
insert into test values(generate series(1,100));

5、做基础备份

pg_basebackup -Ft -Pv -Xf -z -Z5 -D /pg_base/’date +%F’

6、手动归档wal日志

select pg_switch_wal();		#手动归档wal日志

7、模拟误删data文件夹数据

mv /var/bin/pgsql/14/data	/var/bin/pgsql/14/data.bak	#重命名原来的data文件夹
mkdir data	#创建新的data文件夹

8、解压基础备份至空的data文件夹

cp /pg base/base.tar.gz  /var/bin/pgsql/14/data   #拷贝基础备份到新建data文件夹
tar -zxvf base.tar.gz		#解压文件
cd /var/bin/pgsql/14/data	
rm -rf pg wal
rm -rf postmaster.pid	#删除基础备份中的wa1日志和postmaster.pid文件
mkdir -p pg_wal/archive status	#创建archive status文件夹

9、修改配置文件

vi postgresql.conf
#修改restore command为要恢复的wa1日志目录
restore command = ‘cp /archive/%f %p’

10、新建recovery.signal文件

touch recovery.signal	#恢复时依赖该文件,恢复至最新wal位置

11、查看wal日志

查看pggresql日志 查看pg数据库日志位置_hive_03


wal日志的名称,是三块内容组成,

每8个字符分成一组,用16进制标识的

00000001 00000000 0000000A
时间线    逻辑id    物理id

12、赋权并重启数据库

#新建的data文件夹更改所有者
chown -R postgres:postgres /var/bin/pgsql/14/data

#修改data目录权限,否则会因为目录权限过大无法启动数据库
chmod 0700 data –R

#重启数据库
systemctl restart postgresql-14.service

数据库恢复成功:

查看pggresql日志 查看pg数据库日志位置_数据库_04


1.6 实例描述

假设在数据库在写入过程中突然发生故障,导致某个数据文件损坏。在这种情况下,可以使用WAL文件进行数据恢复。
故障发生前
1. 确保数据库已经配置了WAL日志记录,并且启用了归档模式。这样,WAL日志文件会被自动备份并保存在归档目录中。
2. 定期备份您据库数据文件,以防止数据丢失。

故障发生后
1. 首先,检查数据库的状态。可以使用pg_stat_activity视图检查当前的活动进程,确保没有未完成的事务。如果有未完成的事务,需要回滚这些事务,确保数据库的一致性。
2. 然后,检查损坏的数据文件。可以使用pg_ls_data视图列出数据目录中的文件,并确定损坏的数据文件。
3. 接下来,确定损坏数据文件对应的WAL日志范围。可以使用pg_xlogloc或pg_current_xlog_location函数获取当前的WAL位置,并与损坏数据文件的时间戳进行比较,确定需要恢复的WAL日志范围。
4. 使用pg_restore工具恢复数据。假设已经备份了损坏数据文件之前的WAL日志,可以使用pg_restore工具从WAL日志中恢复数据。

在命令行中执行以下命令:

pg_restore -l mydb_backup.tar -L mydb_archive /path/to/mydb_archive/000000010000000000000001.00000028.backup

其中,mydb_backup.tar是备份文件,mydb_archive是归档目录,/path/to/mydb_archive/000000010000000000000001.00000028.backup是要恢复的WAL日志备份文件的路径。
5. 在恢复过程中,pg_restore工具会根据WAL日志中的信息将数据恢复到数据库中。等待恢复过程完成即可。
6. 恢复完成后,检查数据库的状态和完整性。确保所有的数据都已正确恢复并且数据库运行正常。