持久化 · XB 现场笔记

RDB 与 AOF：两种保住 Redis 的方式

Tue, 15 Jun 2027 00:00:00 +0000

RDB 与 AOF 保存的是 Redis 状态的不同表示。选择之前应回答两个问题：允许丢失多少近期数据，以及可以接受多长恢复时间？单独一个持久化开关无法回答这些问题。真正需要的是可恢复的文件、明确的写入确认策略，以及验证过具体数据值的恢复流程，而不只是能够启动的进程。

快照记录一个时点，不保证固定间隔

RDB 是紧凑的时点数据集。BGSAVE 派生子进程，先写临时文件，完成后再替换旧快照；父进程继续处理请求，但派生进程、写时复制增加的内存以及磁盘工作仍有成本。SAVE 则同步保存并阻塞其他客户端，本文只把它用于很小的隔离测试数据，不应照搬到繁忙服务上。

例如 save 60 1000 同时要求经过指定时间并达到修改次数条件，不是“无论有多少修改，每六十秒都必定生成一份快照”，也不保证保存能按时成功完成。实际恢复暴露窗口取决于最近一份可用快照的状态有多旧；漏掉或失败的保存会扩大这个窗口。因此，要检查成功保存的记录与结果，不能只看配置中的时间数字。

AOF 改变恢复数据的表示

AOF 记录数据变更，并按 appendfsync 策略同步。everysec 通常暴露大约最近一秒的写入，no 把刷盘时机交给操作系统；always 在有效配置允许的情况下先同步再回复，代价是额外的同步开销。这些策略不保护整块存储设备丢失，也不能保证故障切换时被提升的副本包含每一条已经在原节点落盘的写入。

现代 AOF 是 manifest、基础文件和增量文件组成的集合，基础文件可以使用 RDB 格式。因此，“AOF 启动必定从头回放庞大的文本历史”不准确；重写还会去掉重建当前状态不再需要的历史操作。文件大小、启动耗时、重写开销和请求延迟，应结合实际数据集测量，不能仅凭 RDB 或 AOF 的名称排序。

两者同时启用，不等于自动合并

在没有额外启动覆盖的通常配置下，启用了 AOF 的 Redis 会选择 AOF 恢复，而不是先独立加载 dump.rdb，再把另一份日志叠加上去。AOF 内部的 RDB 格式基础文件属于其自身文件集合。另行保留的 RDB 仍可用于备份和明确选择的恢复操作，但不会自动补齐缺损的 AOF 文件。

已有的 RDB 部署也不能仅修改 appendonly 然后直接重启。应遵循官方的在线转换流程，等待初始 AOF 成功生成，并把配置持久化，之后再考虑重启。下面的两个测试分别从空目录开始，目的在于比较恢复语义，绝不是迁移已有数据库的操作清单，更不应替换成生产目录运行。

坏掉的样子

BGSAVE 请求成功只代表请求被接受，不代表快照已经成功完成。存储写入失败、无法创建子进程或磁盘空间不足，都可能让实际可用恢复点停留在很久之前。需要结合 INFO persistence、错误日志和资源余量判断；即使 Redis 仍能回复请求，后台持久化也可能已经失败或显著恶化尾延迟。

如果唯一文件副本与服务位于同一台机器、共享同一个故障范围，那么两种格式都还不能算独立备份。应在机器之外保留一致副本，并实际恢复验证。AOF 会保存应用误删的结果，快照也可能已包含同一个错误。历史留存和应用层数据核验，不能被“进程已经可以接受连接”代替。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar，以及 Python 3.10 以上版本。实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上执行。以下步骤只用 libc 构建 Redis 核心，将客户端装进临时虚拟环境，不改变系统级安装。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行 Python 代码。每组测试都有独立目录和 Unix socket，不监听 TCP，不安排自动快照。两组都主动保存一份小快照，只有第二组启用 AOF，并使用 always、保持重写期间同步。SIGKILL 只作用于代码创建的子进程；数据文件保留到重新启动并核验完成，随后清理临时目录。

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


for aof in (False, True):
 with TemporaryDirectory(prefix="redis-restore-", dir="/tmp") as directory:
 with instance(directory, aof) as (client, process):
 assert client.set("version", "snapshot")
 assert client.incr("counter") == 1
 assert client.save()
 snapshot = (Path(directory) / "dump.rdb").read_bytes()
 assert snapshot.startswith(b"REDIS")
 assert client.set("version", "after-snapshot")
 assert client.set("later", "present")
 assert client.incr("counter") == 2
 if aof:
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 crash(process)

 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 with instance(directory, aof) as (client, process):
 expected = ([b"after-snapshot", b"present", b"2"] if aof
 else [b"snapshot", None, b"1"])
 assert client.mget("version", "later", "counter") == expected
 assert client.dbsize() == (3 if aof else 2)
 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 print("RDB + AOF" if aof else "RDB only", expected)
print("an unchanged standalone RDB does not override enabled AOF recovery")

RDB-only 恢复出的 version 是 snapshot，later 键不存在，计数器是一；启用 AOF 的那组得到 after-snapshot、后来写入的 later 键，以及计数器二。两组的独立 RDB 文件字节在进程被杀和检查重启期间都保持不变，说明第二组不是因为偷偷又保存了一份新快照才恢复更新的数据。

计数器刻意没有先用 SET 初始化：快照里已有一，如果错误地把两次递增再回放到它上面，结果就会变成三，而不是正确的二。这让实验能够检查状态语义，而不只是确认进程启动或键数量相同。

SIGKILL 跳过正常关闭，但并没有让操作系统崩溃，也没有清空文件系统缓存。因此，该实验建立的是快照恢复边界和通常的 AOF 启动选择，并未验证断电、备份传输完整性、副本故障切换或生产数据量下的恢复时间。作出更强承诺之前，应为这些情形分别安排验收。

来源

Redis 持久化，快照、AOF 启动选择、在线转换与备份，已核验 2026-09-08。
Redis SAVE，同步快照行为与阻塞成本，已核验 2026-09-08。
Redis BGSAVE，后台保存及请求被接受的含义，已核验 2026-09-08。
Redis INFO，持久化进度与结果字段，已核验 2026-09-08。
Redis 8.10.1 配置，快照触发条件与 AOF 策略，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

WAL 让提交持久化不必等待所有数据页刷盘

Fri, 14 Aug 2026 00:00:00 +0000

预写日志允许数据库把事务变成持久状态，而不必立即刷出这个事务修改过的每一个表页与索引页。在 PostgreSQL 中，恢复某个页面所需的日志，必须在这个页面写入存储之前先持久化。正常同步提交还会等待提交记录完成刷盘。因此，缓冲区里的表变更与已经持久化的日志记录，沿着不同路径向前推进。

坏掉的样子

WAL 不是一张稍后再执行 SQL 的预约单。执行过程已经修改内存页面，日志记录描述的是恢复动作。有些日志来自最终没有提交的事务。恢复需要结合重做与事务状态，确保一个未完成事务不会仅因部分日志或数据页已经落盘，就变成其他查询可见的提交结果。把“日志存在”当成“事务已经成功”，会误解恢复后数据的可见性。

持久性设置会改变承诺。关闭同步提交后，成功响应可能先于日志持久化，崩溃时最近已经确认的事务因此可能消失。关闭文件同步的风险更大，系统故障后甚至可能留下不一致存储。整页写入解决的是另一类问题：在页面只写入一部分时，提供重新构造页面的材料。这些机制都无法弥补存储虚假确认同步，也不能补回所有持久副本同时丢失的数据。

客户端没有收到回复，又是另一种不确定性。服务端可能已经成功提交，连接随后才断开。恢复后事务仍然存在，客户端却从未看到成功，此时直接重试业务动作可能造成重复。因此，对需要保证业务操作唯一性的场景，应使用稳定操作标识并核对结果，不能把网络失败一概解释成数据库已经回滚。

快速验证

在 Linux 环境中，以非超级操作系统账户运行脚本，并准备 PostgreSQL 18 服务端与客户端程序。本次实际使用 PostgreSQL 18.6。脚本初始化隔离的临时集群，使用私有 Unix 套接字，并显式开启正常持久性设置。立即停止操作只针对它刚创建的集群。因为演练会故意打断数据库进程，应使用完整测试夹具，不要把路径替换成生产数据目录。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-crash.XXXXXX)
mkdir "$lab/socket"
cluster=$lab/data
writer_pid=''
cleanup() {
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 if test -n "$writer_pid"; then wait "$writer_pid" || :; fi
}
trap cleanup EXIT
initdb -D "$cluster" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$cluster/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
fsync = on
synchronous_commit = on
full_page_writes = on
checkpoint_timeout = '1h'
CONF
pg_ctl -D "$cluster" -l "$lab/server.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'base');
CHECKPOINT;
SQL
checkpoint_before=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT checkpoint_lsn FROM pg_control_checkpoint()')
psql -X -v ON_ERROR_STOP=1 -qAt -c "INSERT INTO marker VALUES (2,'committed')"
commit_end=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_current_wal_lsn()')
test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_current_wal_flush_lsn()>='$commit_end'::pg_lsn")" = t
PGAPPNAME=crash_uncommitted psql -X -v ON_ERROR_STOP=1 -qAt >"$lab/writer.log" 2>&1 <<'SQL' &
BEGIN;
UPDATE marker SET value='uncommitted' WHERE id=1;
SELECT pg_sleep(120);
COMMIT;
SQL
writer_pid=$!
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT EXISTS (SELECT FROM pg_stat_activity WHERE application_name='crash_uncommitted' AND wait_event='PgSleep')")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'uncommitted writer was not ready' >&2; exit 1; }
 sleep 0.1
done
test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT checkpoint_lsn='$checkpoint_before'::pg_lsn FROM pg_control_checkpoint()")" = t
echo committed_wal_flushed_without_new_checkpoint
pg_ctl -D "$cluster" -m immediate -w stop >/dev/null
if wait "$writer_pid"; then
 writer_pid=''
 echo 'interrupted writer unexpectedly succeeded' >&2
 exit 1
fi
writer_pid=''
pg_ctl -D "$cluster" -l "$lab/server.log" -w -t 15 start >/dev/null
grep -F 'redo starts at' "$lab/server.log"
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:base,2:committed' THEN
 RAISE EXCEPTION 'crash recovery result mismatch';
 END IF;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

第一行以 base 值完成检查点。随后脚本提交第二行，并核对已经刷出的日志位置覆盖提交之后捕获的位置。另一个后端在事务里修改第一行，然后在提交之前进入休眠。通过统计视图观察该后端真实进入休眠状态，证明这项未完成更新确实执行了，而不是只把一条尚未送达数据库的命令放在客户端等待。

中断之前，控制文件中的检查点位置必须仍然等于基线。因此，已经确认的插入并不需要另一个检查点。立即停止会打断休眠后端，而且不执行正常关闭检查点。脚本要求这个客户端操作失败，再启动同一个集群，并检查服务端日志中是否真正开始重做。

恢复后必须得到第一行 base、第二行 committed。SQL 断言会拒绝缺行、多行或内容错误的结果。已提交事务被保留，未完成更新不可见。这不能证明某个具体页面一定由重做重新生成，而不是之前已经被后台活动写出；它验证的是存在待决工作且数据库真实被中断时，最终恢复状态符合事务契约。

脚本退出时停止恢复后的集群，并打印保存日志的目录。它没有模拟整机断电、磁盘缓存虚假确认、卷丢失或远端复制故障，这些情形需要各自的恢复证据。特别是进程重启仍然保留宿主机操作系统状态，不能从这个演练推导出所有硬件故障下的保证。

核算完整写入路径

追加日志可以避免每次提交都强制写出分散的数据页，但代价并没有消失。日志仍然消耗带宽、同步等待、存储与复制容量，整页镜像还可能扩大日志流。脏页最终仍需写回，检查点提供恢复起点，并不免除这些工作。把 WAL 描述成简单的一次复制，会漏掉后续数据页写入和恢复期间的成本。

应同时测量提交延迟、日志生成、检查点行为与恢复耗时。通过削弱同步来缩短确认延迟，改变的是持久性承诺，不能当成语义完全相同的优化。还要把本地崩溃恢复与归档恢复、故障切换的保证分开记录。真正有用的结论，是明确哪些已经确认的事务可以恢复，以及这个结论覆盖了实际演练过的哪种故障模型。

来源

PostgreSQL 18 WAL 入门，预写顺序及无需立即刷出数据文件的提交，已核验 2026-09-11。
PostgreSQL 18 WAL 配置，同步提交、文件同步和整页写入保证，已核验 2026-09-10。
PostgreSQL 18 WAL 与检查点调优，数据写回、检查点和恢复工作，已核验 2026-09-12。