postgres WAL归档
一,关于WAL归档
事务提交后，对系统的影响必须是永久的，即使系统意外宕机，也必须确保事务提交时的修改已真正永久写入到永久存储中。最简单的实现方法，当然是在事务提交后立即刷新事务修改后的数据到磁盘。但是磁盘和内存之间的IO操作是最影响数据库系统影响时间的，一有事务提交就去刷新磁盘，会对数据库性能产生不好影响。WAL机制的引入，即保证了事务持久性和数据完整性，又尽量地避免了频繁IO对性能的影响。
二,WAL 机制说明
(摘录:https://www.cnblogs.com/VicLiu/p/11854782.html)
Write-Ahead Logging，前写日志。
在MVCC的部分中，我们已经分析了PostgreSQL的存储结构：元组-文件页-物理段-表；
以及写数据的步骤：先写到缓冲区Buffer-再刷新到磁盘Disk。
WAL机制实际是在这个写数据的过程中加入了对应的写wal log的过程，步骤一样是先到Buffer，再刷新到Disk。
- Change发生时：
- 先将变更后内容记入WAL Buffer
- 再将更新后的数据写入Data Buffer
- Commit发生时：
- WAL Buffer刷新到Disk
- Data Buffer写磁盘推迟
- Checkpoint发生时：
- 将所有Data Buffer刷新到磁盘
通过上面的分析，可以看到：
当宕机发生时，
- Data Buffer的内容还没有全部写入到永久存储中，数据丢失；
- 但是WAL Buffer的内容已写入磁盘，根据WAL日志的内容，可以恢复库丢失的内容。
在提交时，仅把WAL刷新到了磁盘，而不是Data刷新：
- 从IO次数来说，WAL刷新是少量IO，Data刷新是大量IO，WAL刷新次数少得多；
- 从IO花销来说，WAL刷新是连续IO，Data刷新是随机IO，WAL刷新花销小得多。
因此WAL机制在保证事务持久性和数据完整性的同时，成功地提升了系统性能。
三,相关参数开启
01, wal_level参数
该参数的可选的值有minimal，replica和logical，wal的级别依次增高，在wal的信息也越多。由于minimal这一级别的wal不包含从基础的备份和wal日志重建数据的足够信息，在该模式下，无法开启wal日志归档,所以开启归档至少是replca级别的
ALTER SYSTEM SET wal_level =’replica’;
02, archive_mode参数
archive_ mode参数可选的值有on、off和always，默认值为off，开启归档需要修改为on
ALTER SYSTEM SET archive mode =’on’
03, archive_command参数
archive command参数的默认值是个空字符串，它的值可以是一条shell命令或者一个复杂的shell脚本。在archive_command的shell命令或脚本中可以用“%p”表示将要归档的WAL文件的包含完整路径信息的文件名，用“%f”代表不包含路径信息的WAL文件的文件名。一个最简单的archive_command的例子是：archive_command =’ test ! -f /data/archive/%f && cp %p /data/archive/%f'。
当然最需要注意的还是上面的参数是需要重启数据库的,但是archive_commang 可以软重启
