-
打下时空锚点：
在业务持续高并发写入（内存不断变化）的动态环境中，如何精确划定一条“时间分割线”，并确保这条分割线之前的所有数据，100% 写入底层的物理磁盘。 以下是 SELECT pg_start_backup() 在系统底层执行的 5 个绝对因果步骤。逻辑不跳跃，严格按照源码执行顺序推演： 第一步：API 接收与进程间硬中断触发 【前置 ...
-
多进程旁路读取
阶段一：物理环境隔离与契约建立 (Initialization) 前因： 灾难恢复的工程基线要求备份数据必须脱离当前运行主机的故障域。同时，备份工具需要独立管理自身的元数据、压缩配置和保留策略。 执行过程： 1. 执行 pg_probackup init 和 add-instance。 2. 工具在指定的外部存储路径上调用 Linux mkdir 系统调用， ...
-
确立时空锚点 (Generating the Anchor LSN) 这个锚点这么确定
Anchor LSN（也就是 pg_start_backup 返回的 Start LSN）绝对不是 Checkpoint 记录的“下一个 LSN”。它在物理坐标上，完完全全、精准无误地等于那个 REDO LSN 本身！ 我们直接在内存和磁盘之间拉一根时间轴，用最严谨的 C 语言内核逻辑，放慢这几秒钟的底层物理动作，看看这个“锚点”到底是怎么打下去的： 物理级 ...
-
检查点进程运行机制
阶段一：锚定绝对时空坐标（获取 REDO LSN） 检查点启动的第一步，是在不阻塞业务读写的前提下，在 WAL 日志流中打下一个“物理地基”。 抢占轻量级锁：Checkpointer 进程短暂获取 WAL 插入锁（WALInsertLock）。 打下 REDO 指针：它读取当前 WAL 缓冲区中最新的字节偏移量（LSN）。这个 LSN 被标记为 REDO L ...
-
restore_command 里面的内容 详解
🧬 核心宏替换：内核与 Shell 的变量交接 当你写下 restore_command = 'cp /arch/%f %p' 时，PG 内核在执行它之前，会进行极其精准的字符串宏替换（String Substitution）： 1. %f：死亡录像带的“纯净编号” 物理真相：它仅仅是一个 24 字节长的纯字符串（由时间线 ID + 逻辑 LSN 组成）。 替换结果：例如 ...
-
pg_basebackup工具备份的时候，会不会把 服务端 表空间里面的数据备份？
绝对会！百分之百会！它不仅会备份，而且会把表空间里最底层的真实物理数据块，一字节不差地全部抽空带走！ 🧲 物理抓取全过程（拒绝空壳） 当 pg_basebackup 在主库上开始收容数据时： 扫描与发现：它扫描主数据目录（$PGDATA），来到了 $PGDATA/pg_tblspc/ 目录。 识破软链接：它看到了里面名叫 16384 ...
-
pg_basebackup备份的文件有哪些？？
📦 阵营一：被完整打包的核心数据（在 $PGDATA 内部） 这是数据库的“肉身”，pg_basebackup 会毫不犹豫地将它们按原样复制（或打包成 base.tar）： base/：默认表空间。里面按 OID 存放了你创建的各个数据库的真实表数据和索引数据（也就是那些 8KB 的数据块）。 global/：全局字典。包含整个集群的共享系统 ...
-
时间点恢复过程中，recovery.singal文件没有被删除期间，数据库处于什么状态
💽 内部面孔：存储引擎层（高强度“纯写”状态） 主导进程：Startup 进程（数据库启动时拉起的第一个子进程）。 物理行为：它在后台以极高的 CPU 和 I/O 资源占用率，疯狂读取归档或流复制传来的 WAL 日志，并将这些日志中的 INSERT/UPDATE/DELETE 物理变更，逐字节地写入内存（Shared Buffers）中的 8KB 数据页 ...
-
select pg_wal_replay_resume(); 这条命令的作用
🛑 物理前置条件：悬崖勒马的默认设置（pause） 隐蔽的参数：在 PostgreSQL（尤其是 PG 12 及以后的版本）中，当你配置了恢复目标（比如 recovery_target_time = '15:00:00'）时，有一个极其关键的隐蔽参数叫 recovery_target_action。 默认的底线：它的默认值是 pause（暂停）。 发生什么了？ 当 Startup ...