Synod 发布多写 PostgreSQL 集群数据库，每个节点都能读写

多个写入者的 PostgreSQL 运行在共享存储上 Synod 可以在同一批表上运行最多八个 PostgreSQL 写入者，并共用一份数据副本，方式与 Oracle RAC 类似。当某个写入者发生故障时，其他写入者会将其隔离并继续运行，无需任何中央协调器。已确认的事务不会丢失，也不会被写入两次。 它基于 Neon 的开源存储构建，该存储由我们在自己的仓库中维护。Synod 增加了多写入者引擎、写入者自己的集群成员管理、可拆分为分片并故障转移到备用节点的存储，以及在你自己的服务器上运行它的安装程序和控制平面。 没有脑裂。31,063 项变更已确认，0 项缺失，三个写入者上的行完全一致。 curl -fsSL https://synoddb.com/try.sh | sudo bash 复制 已复制 在一台全新的 Ubuntu 24.04 机器或虚拟机上运行：x86-64，内存 8 GB 或更多，可用空间 20 GB。它会下载试用包（106 MB），校验其校验和，并安装三个日志服务器、一个页面服务器、控制平面，以及一个包含三个写入者的集群，全部作为该机器上的服务运行。然后它在每个写入者上提交一行，检查每个写入者都能看到全部三行，并打印连接方式。在全新的 AWS 机器上，这个过程大约需要一分钟，包含下载时间。 sudo synod-try kill-writer b 会在另外两个写入者继续提交的同时杀死某个写入者的 Postgres；在我们的测试机器上，它在 2 到 4 秒内恢复服务。freeze-writer c 会让某个写入者的所有进程停止 45 秒：另外两个会在 30 秒后将其驱逐并继续运行，而它会在约 50 秒时重新加入。 同一个包可以通过 SSH，根据清单文件在你自己的多台机器上安装集群，并使用一个 S3 桶作为其对象存储。README 中说明了具体方法。 原型：可免费试用，按原样提供，闭源，受试用条款约束。请勿用于生产数据，并且需要私有网络：写入者之间的流量尚未加密。无遥测。 如果你愿意，可以先阅读脚本，或者下载包（SHA-256）并在其中运行 sudo ./synod-try。告诉我们它在哪出现问题：contact@synoddb.com。 AWS 上的速度，预热缓存，2026 年 11 月 1 日 三个写入者时单个写入者的读写速度：每秒 3,726 个事务，对比 1,645（pgbench TPC-B，每台服务器 16 个客户端） 在 32 vCPU 机器上、三个写入者时的每秒读取次数，是同等规模单机 PostgreSQL 的 1.84 倍（481,806） 失败事务数：在每个 Synod 提交都写入三台日志服务器中的两台、且位于其他机器上、并且在客户端收到响应之前的情况下 读写：三个写入者与单独 PostgreSQL 在 8 vCPU AWS 机器上的对比。读取：在 32 vCPU 机器、每台服务器 64 个客户端上的相同对比。数据位于内存中，两者均使用 TLS。完整表格及我们的测试方式。 在九次写入者故障中，309,727 项已确认变更里缺失的变更数 随机故障，每次检查都一致，其中 8 次同时发生第二个故障 在 PostgreSQL 自带的回归测试套件之后，三个写入者上的表完全相同 在负载下杀死一个页面服务器后，每个写入者迁移到备用页面服务器所需的时间，0 错误且无任何丢失 原型软件，于 2026 年 10 月和 11 月在 AWS 上测试。完整结果及我们的测试方式见 Results 和 Testing 标签页。 在一次 6.3 小时的 AWS 运行中加载到三个写入者的表中，约 53 亿行，同时存储从 8 个分片自行拆分为 32 个；在此之前，9 小时加载了 496 GB，以及在负载下存储拆分时加载了 235 GB 在那次运行中发现一个修复后更快的批量加载：表现在一次增长数页，而不是一页 在主进程被杀死且后台进程卡住后，写入者恢复所需的时间；在修复前，这曾让一个写入者在 AWS 上停机一小时 这些运行发现的七个问题中，六个已修复并通过测试检查，其中最严重的三个通过故意强制触发它们的测试检查，还有一个修复正在测试中。11 月 2 日至 3 日的另外两次运行在 AWS 上检查了这些修复，并又发现了一个问题，次日已在 AWS 上修复并检查。11 月 3 日至 4 日的 TB 级运行及该规模的测试又发现了五个问题，均已修复。出了什么问题、为什么，以及我们改了什么。 PostgreSQL 集群只有一个可以写入的服务器。每个副本保留自己完整的数据副本，而当写入者死亡时提升其中一个副本，则留给外部工具处理。 如果旧写入者只是不可达而非已死亡，它可能继续接受永远不会被看到的写入。防止这种脑裂是任何故障转移设计中最困难的部分。 为在共享存储上运行多个写入者而使用 Oracle RAC 的团队，没有对等的开源 PostgreSQL 选项可以迁移。 在 PostgreSQL 上实现共享存储上的多个写入者和安全故障转移，无需 Oracle 按处理器收取的数据库许可及其 RAC 选项费用。 任意写入者均可提供服务，故障写入者会被隔离并自行重启，已确认的提交得以保留。它运行在你自己的服务器或云账户中。 你的 Oracle 到 PostgreSQL 项目中不得不留在 Oracle 上的 RAC 数据库。带来一个，我们共同开展试点；迁移工作仍由你负责。 PostgreSQL 17，多台服务器通过一份共享数据副本写入相同的表。丢失一台服务器，保留每一次提交。 每个 Synod 集群一个控制台和命令行：健康、性能、Cache Fusion 和管理操作，在你自己的网络中运行。 我们正在寻找几位设计合作伙伴，在非生产副本上进行免费试点，并由构建它的团队提供直接支持。 数据库服务器本身不持有数据。每个写入者的变更都会发送到三个日志服务器，当其中两个将其写入磁盘后即计入，页面服务器按请求重建任何页面，每个页面服务器都有一个备用节点，在其故障时接管。Synod 增加的部分位于写入者之间。 每个页面都有一个管理写入者，通过哈希选择。需要修改某个页面的写入者会向该写入者请求权限，并直接从当前持有该页面的写入者那里获取最新副本，方式与 RAC 的缓存融合类似。 每个写入者按照写入者之间保持同步的时钟为自己的提交编号。其他每个写入者在客户端被告知成功之前都会得知该提交。旧行版本保存在 undo 日志中，因此读取者从不需要等待写入者。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）