foolishlee的博客

原创 Neon safekeeper任务

静态变量定义），每个 runtime 运行在独立的 OS 线程池上，从而把 WAL 服务、HTTP 管理接口、Broker 通信、备份导出和后台维护任务彼此隔离，避免某一类任务阻塞影响其他关键路径。safekeeper 使用 5 个独立的 Tokio Runtime（通过。

原创 Neon 租户数据分片

其中compute 端（

原创 Neon PageServer的gRPC和PageStream

简单说：gRPC 是 pagestream 的新一代替代方案，功能等价但用 Protobuf + HTTP/2 重做了，预期性能更好、更易维护。3. Shard 路由：gRPC 通过 neon-shard-id header 指定，client_grpc/src/split.rs 自动拆分跨 shard 请求。// LSN 租约（防 GC）

原创 Neon index_part.json

每个 timeline 在对象存储里都有一个。

原创 Neon Safekeeper 的多数派协议：自定义的 term-based quorum 共识

Paxos 也用了 term/latchman 概念，但 safekeeper 的协议更接近「基于 proposal 的复制」而非经典 Paxos 的 prepare/accept 两阶段。自定义的 term-based quorum 协议，吸取了 Raft/Paxos 的思路但有自己的设计。

原创 Neon compute GetPage

2. LSN 语义：请求携带 (request_lsn, not_modified_since) 两个 LSN，primary 端 request_lsn=UINT64_MAX（最新），replica。│ nm_pack_request() // 序列化（pq_send...）├─ prefetch_wait_for(ring_index) // 阻塞等待响应。neon_read() (PG≤16) // 单块读取。

原创 Neon 组件连接

原创 openGauss同步提交

惊群问题：是的，有。2. 串行锁简化了状态机——只有"持有锁的那个人"需要关心 LSN 是否满足，其他人只是排队等锁，避免了多 backend 同时被唤醒后的竞争。1. PG 的 SyncRepQueue 机制是为单机设计的，在分布式架构下，多个 DN 之间需要同步协调，批量队列唤醒的语义不够清晰。│ 唤醒方式 │ 一次唤醒所有满足LSN的backend │ 只唤醒当前持锁的1个backend │。│ 并发等待 │ N个backend同时等latch │ 只有1个在等，其余阻塞锁 │。

原创 SCRAM-SHA-256

服务器：连接建立。

原创 Rust 下载依赖包

这步需要能访问 crates.io（和 git 仓库）。生成后会得到 Cargo.lock。会创建 vendor/ 目录（所有依赖源码）和 vendor.toml（映射表）。此时 cargo 不会联网，完全从 vendor/ 读取源码。

原创 Neon 计算节点日志缓冲合并逻辑解析

在。

原创 Neon 计算节点启动报错exists already. please don‘t do this, it is not supported.

根据代码分析，问题出在函数（），它检查是否存在同一上处于非Stopped状态的 endpoint。计算节点异常退出后可能留下了残留的文件，导致status()返回Crashed而非Stopped，从而触发冲突校验。

原创 Neon proxy云端控制面

调用 get_role_access_control → GET {base}/get_endpoint_access_control?endpointish=...&role=...- role_secret 是 SCRAM 格式的密码哈希（SCRAM-SHA-256$<iterations>:<salt>:<stored_key>:<server_key>）- cold_start_info 枚举值: warm / vm_pool_hit / vm_pool_miss / unknown。

原创 openGauss xlog清理

XLog 清理的唯一入口是 RemoveOldXlogFiles()（xlog.cpp:5404），在每次 Checkpoint 时调用。判断"哪些可以删"的逻辑集中在 KeepLogSeg()（xlog.cpp:14149），该函数计算最老的可保留 segment 号，比它更老的会被 RemoveXlogFile() 回收或删除。---一、全部影响因素1. wal_keep_segments 配置参数- 默认 16，范围 2~INT_MAX（guc_storage.cpp:2737）

原创 Neon proxy and local_proxy

local_proxy.rs → cargo run --bin local_proxy （精简版）--auth-backend postgres 和 --auth-backend local 啥区别。client ──SCRAM auth──▶ proxy ──转发流量──▶ postgres。client ──无认证──▶ proxy ──直接转发──▶ postgres。它直连你本地的 postgres，连接过来就直接转发，不做额外认证。不需要建任何 schema，不需要认证，适合开发调试。

原创 openGauss postmaster退出流程

/ 当前 PM 状态// 关机请求级别Shutdown 级别（由信号设置）：- SmartShutdown = 1（SIGTERM，等事务结束）- FastShutdown = 2（SIGINT，立即回滚事务）- ImmediateShutdown = 3（SIGQUIT，直接退出）PMState 状态机序列（正常关机）：---

原创 Neon 扩缩容代码仓

neonvm/apis/neonvm/v1/zz_generated.deepcopy.go —DeepCopy 方法。- neonvm/client/ —Go 客户端代码（clientset/informers/listers）- bin/controller-gen —CRD/WebView 代码生成。- bin/kind / bin/k3d —本地集群工具。- bin/setup-envtest —单元测试环境。- bin/etcd —测试用 etcd。- bin/yq —YAML 处理。

原创 Neon Scale-to-Zero

问题答案Scale-to-Zero 是什么？空闲时停止整个 compute Pod，有连接时再启动K8s 的作用？管理 Pod 的生命周期（创建/删除），提供 DNS 路由谁负责唤醒？Proxy 调用 Console API，Console 创建新 Pod去掉 Proxy 会怎样？Scale-to-Zero 无法工作，客户端无法自动找到新 Pod这不是一个纯技术取舍，而是 serverless 架构的核心设计：Proxy 是 scale-to-zero 的"扳机"，没有它就无法实现按需启停。

原创 Neon proxy

参数默认值作用调优方向到同一 compute 的并发连接限制高并发可调大 permitspermits=0（禁用）唤醒 compute 的并发限制如启用可调大4SCRAM 哈希线程数大量新连接时调大15sTLS 握手超时网络慢时调大连接 compute 重试策略可靠性参数wake_compute 重试策略可靠性参数endpoint 新连接限流压测时调大类似wake_compute 限流按需调整compute 地址缓存调大减少 cplane 调用endpoint 访问控制缓存。

原创 Neon get_page(key, request_lsn)

但注意，如果当前请求的 LSN 本身就落到了 Image 层上或刚好在某个 Delta 层的范围内，那么只会读那个层就够了，不一定会"下潜"到更深的 Image 层——除非那个 key 在当前层没有记录。用 R-tree + 有序迭代器遍历 historic 层，找到所有覆盖该 key 范围的层，返回每个层的 (layer, lsn_floor, lsn_ceil)。image 层是 WAL redo 的起点（base state），delta 层的 WAL record 是增量修改。

原创 Neon 数据读取

在调用任何 smgr 操作之前，PostgreSQL 的 buffer manager 会先检查目标页面是否在 shared buffer cache 中（这是 PG 内核行为，Neon 不介入）。如果命中，直接返回，整个 smgr 路径都不需要执行。所以虽然读取路径不检查 LSN，但写入时的 LwLSN 检查保证了 LFC 中的数据不会落后于已提交的修改。当 shared buffer miss 后，调用。

原创 opengauss 同步提交

同步提交（synchronous_commit = on）的语义是：确保事务提交记录在主机和备机都已持久化后，才返回客户端成功。至于事务执行过程中产生的大量数据 WAL，都是异步处理的，不逐条同步。这也就解释了为什么批量插入（5000 次 XLogWaitFlush）的性能瓶颈不在于这些等待，真正的影响只在于事务最终 commit 时那一次 SyncRepWaitForLSN。

原创 Neon pageserver layer文件

│ ┌──────────┐ WAL 写入 ┌──────────┐ 冻结 ┌──────────┐ │。│ │ (活跃) │ │ (内存) │ │ (只读) │ │。│ │ │ Evicted │── 按需下载 ──>Resident │。

原创 Neon pageserver Heatmap

HeatMap 是按租户维度生成的，每个租户拥有一个独立的 HeatMap。项目大小HeatMap JSON 元数据50KB-500KB层文件总大小（S3 中）几百 MB 到几 GB次级缓存大小（热层）根据热度分数，通常 10-100GB问题答案HeatMap 包含多个租户吗？❌ 否，每个租户一个独立 HeatMapHeatMap 包含一个租户的多个 Timeline 吗？✅ 是，包含该租户所有 TimelineHeatMap JSON 大小？50KB-500KB（元数据）

原创 Neon pageserver副本切换

问题答案是否自动故障切换？✅ 是，Storage Controller 自动完成检测延迟多久？默认 30 秒（心跳间隔 5 秒 ×6 次超时）切换方式？自动将 Secondary 提升为 Attached原主节点恢复后？降级为 Secondary，重新预热缓存是否需要人工干预？❌ 不需要，完全自动化。

原创 Neon wal日志处理流程2

本文深入解析 Neon 数据库中 WAL 的解码与传输机制，涵盖 safekeeper 的两种协议模式、解码层次、存储链路以及 logical_message 的特殊处理流程。通过对比传统 PostgreSQL 与 Neon 的架构差异，揭示计算存储分离下的 WAL 处理优化。

原创 Neon wal日志处理流程

本文深入剖析 Neon 数据库架构中 WAL（Write-Ahead Log）从 Compute 节点产生，经 Safekeeper 接收、解码、转发，最终被 Pageserver 摄入并存储的完整流程。重点解析 Safekeeper 的"流解码"与"深度解码"两层机制，以及 Pageserver 如何利用 InterpretedWalRecord 实现计算存储分离，避免传统 WAL Redo 的架构设计。

原创 Neon safekeeper解析wal日志

文件中只有 Value::Image= 文件中可以有 Value::Image 或 Value::WalRecord底层解析：walrecord.rs 负责将原始 WAL 字节转换为结构化的 DecodedWALRecord语义理解：decoder.rs 进一步将解码后的记录转换为具有 Neon 存储语义的 InterpretedWalRecord数据分层：区分 Value 类型（Image/WalRecord）和 Layer 类型（Image Layer/Delta Layer）流程优化。

原创 Neon pageserver walredo

RM_HEAP2 这种修改了实际数据页的 WAL 记录才会被存入 layer 并最终送到 walredo。复制槽相关的 WAL 纯靠 pageserver 自己处理元数据，不经过 walredo。✅ Image 进 batch。✅ 增量进 batch。

原创 Neon initdb.tar.zst

initdb.tar.zst 就是 Postgres initdb 命令的原始输出 —一个空白的数据库模板（template1, template0, postgres 库），不包含任何 neon 相关内容。│ 2. upload_initdb() // 压缩上传 →remote storage 的 initdb.tar.zst。├── 起点: initdb 导入时创建的初始 layer (等价于 initdb.tar.zst 的内容)

原创 TimescaleDB chunk和time_bucket原点

2000-01-01 的 Julian Date= 1970-01-01 的 Julian Date差值 =10957 天(30年中的闰年已计入)Chunk 和 time_bucket 的周边界可能对不齐——chunk 对齐到 Unix epoch（周四基准），对齐到周一。如果需要-- 让 time_bucket 以 1970-01-01 为原点，和 chunk 对齐。

原创 Neon LFC

LFC（Local File Cache）是 Neon compute 端加速读性能的核心机制——把 pageserver 上缓存的页面落到 compute 本地的 SSD/NVMe 上，避免每次读都走网络调用 pageserver。

原创 Neon Pageserver Storage Shard 扩容分析

Neon pageserver 的"扩容"通过 Storage Shard 机制实现。这不是传统意义上对单个 pageserver 水平扩展，而是两层扩容策略：1. Tenant Sharding（分片） —将租户数据打散到多个 pageserver 节点上2. Node Scale-out（节点伸缩） —增减 pageserver 物理节点两者由 storage controller 统一管理。---一、架构总览。

原创 Neon autoscaling vm-builder 代码流程分析

设置构建参数 VM_BUILDER_DISK_SIZE 和 VM_BUILDER_TARGET_ARCH，调用 cli.ImageBuild 执行多阶段 Docker 构建，输出目标镜像（如 vm-alpine:3.19）。- 将系统二进制通过 helper.move-bins.sh 复制到 /neonvm/bin/，依赖库放到 /neonvm/lib/2. ::once:/neonvm/bin/touch /neonvm/vmstart.allowed ←允许 vmstart 启动。

原创 Neon autoscaler-agent

Patch 就是指 autoscaler-agent 调用 Kubernetes API，对已有的 VM 资源对象做 增量修改（JSON Patch），而不是删除重建。- 扩容：agent →scheduler plugin 检查节点资源预留 →NeonVM CRD patch →通知 vm-monitor。- 缩容：agent →vm-monitor 确认安全 →NeonVM CRD patch →通知 scheduler plugin。use: 8 # 当前分配 8 Gi 内存。

原创 Neon vm-monitor机制

你说的 inactive_anon + active_anon 是对的，但注意 memory.stat 里的值是字节数，不是 MB。向 agent 发送 UpscaleRequest 消息（runner.rs:446），不是直接扩容，而是请求。2. 取的字段：active_anon + inactive_anon（cgroup.rs:168）3. 不是瞬时值，而是最近 5 个样本（500ms）的平均值（cgroup.rs:113-117）计算 5 个样本的平均值 avg_non_reclaimable。

原创 TimescaleDB 功能

一、Apache 协议下所有可用功能（不含 TSL）

原创 TimescaleDB 函数 timescaledb_create_upper_paths_hook分析

看 replace_hypertable_modify_paths 的逻辑（第 1586-1637 行）：当 output_rel 的 pathlist 包含 ModifyTablePath 且操作是 INSERT/UPDATE/DELETE。如果跳过，其他扩展注册的 create_upper_paths_hook 就不会被执行。③ts_plan_process_partialize_agg（第 1664-1670 行）⑤ts_plan_add_hashagg（第 1679-1680 行）

原创 openGauss添加create_upper_paths_hook方案

create_upper_paths_hook 在 create_upper_paths() 中被调用，每次处理一个 UpperRelationKind 阶段（UPPERREL_GROUP_AGG、UPPERREL_WINDOW 等）1. 语义不匹配：PG 的 hook 操作的是 RelOptInfo.pathlist（Path 级别），openGauss 的规划器操作的是 Plan* 节点树（Plan 级别）。两者数据结构完全不同。

原创 openGauss慢SQL记录相关线程

清理实现: CleanStatementByIdx()（instr_statement.cpp:730）——根据slow_sql_retention_time（慢 SQL 保留天数）和 full_sql_retention_time（全量 SQL。│ track_stmt_retention_time │ 控制保留时间，格式 "full_sql秒,slow_sql天" │。- 实际清理逻辑: CleanStatementTable()（instr_statement.cpp:783）