www.876873.xyz

📡 微操一：Startup Packet 中的“特洛伊木马”（客户端突入）

• 常规的认知：普通业务（比如 Java/Python 程序）连数据库，发的是账号、密码和要连接的数据库名。
• 底层的异变：当你在终端敲下 pg_basebackup 时，它底层的 libpq 驱动在发起 TCP 三次握手后，向主库发送的第一个数据包叫 StartupPacket（启动报文）。
• 凌空劫持：在这个报文里，pg_basebackup 极其隐蔽地塞入了一个核弹级的键值对：replication=true（在 PG 15+ 也可以是 replication=1 或 database=replication 的变体）。
• 物理定性：这根本不是一句 SQL！这是在网络 Socket 刚刚打通的鉴权阶段，直接向数据库内核亮出的一块“最高物理特权令牌”！

🧠 微操二：Postmaster 的命运分叉（服务端的觉醒）

• 大门守卫：主库的 Postmaster 守护进程（PID 1）监听着 5432 端口，收到了这个 StartupPacket。
• 常规路线：如果没看到特权令牌，Postmaster 会 fork() 出一个普通的 postgres 后端进程（Backend）。这个进程会加载庞大的 SQL 解析器、优化器、执行器，准备迎战你的 SELECT/UPDATE。
• 特权路线（The Fork）：Postmaster 看到了 replication=true！它瞬间明白：“来的不是业务，是灾备指挥部！”
• 幽灵诞生：它立刻放弃加载那些沉重的 SQL 引擎，转而极其轻量级地 fork() 出一个专门负责底层二进制流的特种部队——walsender（日志发送进程）。
• 工业级避坑：这个进程不占用主库的 max_connections 配额，它占用的是极其宝贵的 max_wal_senders 配额！很多初级 DBA 发现备份起不来，就是因为不知道它俩在物理配额上是彻底隔离的。

🛡️ 微操三：pg_hba.conf 的异端审判（安全防线）

• 物理拦截：特种兵 walsender 诞生后的第一件事，是进行安全审查。
• 特权黑名单：它去读取主库的 pg_hba.conf 防火墙文件。但是，它绝对不会去看那些普通的数据库授权规则！它只会极其冷酷地扫描一种特殊的伪数据库名——replication。
• 生死判定：如果你没有在 pg_hba.conf 里显式地给这个备份账号配置 host replication backup_user ... 的权限，哪怕你拥有超级管理员（superuser）账号，walsender 也会在这一微秒直接把 TCP 连接物理切断！直接报错 FATAL！

🗣️ 微操四：协议突变与时空对齐（IDENTIFY_SYSTEM）

• 抛弃 SQL：身份核验通过，连接正式建立。但请注意，此时这两个进程之间沟通的语言，已经不再是 SQL 了！ 他们使用的是一套完全独立的、基于二进制的 Streaming Replication Protocol（流复制协议）。
• 开场白：客户端发送的第一条秘密指令不是“给我数据”，而是 IDENTIFY_SYSTEM。
• 时空坐标同步：主库的 walsender 收到指令，立刻返回四组极其核心的底层物理数据：
  1. System ID：主库的绝对物理指纹（防止连错机房）。
  2. Timeline ID：当前处于哪个时空分支（防止脑裂后的时间线混乱）。
  3. XLogPos：当前 WAL 日志写到了哪个精确字节。
  4. Database：当前连接的数据库名。