#ops
2025.9.2 Matrix.org 爆炸回顾
Matrix.org 使用 pgsql 作为他们的数据库。整体架构是主从+推送WAL到S3。
事情起因是数据库硬盘占用已经到了90%（51TiB），所以运维打算添加硬盘。
1. 在机房添加硬盘的时候，主数据库 RAID 阵列里一个已有的硬盘消失了。阵列是RAID10模式所以整个服务器还只是降级。
2. 这时运维打算把流量切到备用服务器上，然后修复主要服务器的阵列问题。调整主从角色之后运维决定重启降级服务器，希望RAID阵列能够自行恢复。
3. 然而RAID阵列没能够自行恢复，直接炸掉所有数据。雪上加霜的是现在的主要服务器上面的WAL->S3脚本被发现有bug，WAL一直没能正确上传到S3。
4. 此时运维团队决定重做整个服务器，并且把备份脚本修好。幸运的是这两者都成功了。这是他们打算开始从备份恢复一个完整实例，于是他们开始用
5. 这次他们打算
6. Matrix实例服务中止（Matrix不应该是去中心化的吗.webp），运维团队决定抛弃现有数据库，开始从冷备份里面开始恢复数据库。然而巨大的数据量+WAL replay消耗了相当长的时间。可喜可贺的是，整个服务还是正常恢复了。
Matrix.org 总结的教训
1. 别把数据库搞得那么大。 Synapse（Matrix.org的实现）正在实现这一点。
2. 增量备份弄的勤快一点，不至于有那么多 WAL Replay。
3. 不要用
4. 不同服务器终端的背景颜色要明显不一样。
5. 用zfs做本地snapshot（在CoW上跑数据库吗？哈基米你这家伙。）
编者评价：其实挺不错的了，至少没丢，而且主要的不可用时间是因为数据传输导致的。（
https://www.youtube.com/watch?v=W42YJYkO8gw
https://matrix.org/blog/2025/10/post-mortem/
2025.9.2 Matrix.org 爆炸回顾
Matrix.org 使用 pgsql 作为他们的数据库。整体架构是主从+推送WAL到S3。
事情起因是数据库硬盘占用已经到了90%（51TiB），所以运维打算添加硬盘。
1. 在机房添加硬盘的时候，主数据库 RAID 阵列里一个已有的硬盘消失了。阵列是RAID10模式所以整个服务器还只是降级。
2. 这时运维打算把流量切到备用服务器上，然后修复主要服务器的阵列问题。调整主从角色之后运维决定重启降级服务器，希望RAID阵列能够自行恢复。
3. 然而RAID阵列没能够自行恢复，直接炸掉所有数据。雪上加霜的是现在的主要服务器上面的WAL->S3脚本被发现有bug，WAL一直没能正确上传到S3。
4. 此时运维团队决定重做整个服务器，并且把备份脚本修好。幸运的是这两者都成功了。这是他们打算开始从备份恢复一个完整实例，于是他们开始用
wal-g 工具来执行。 /mnt/data/postgresql/ # wal-g xxxxx 2>&1 | tee restore.log 结果因为目录非空而失败。然后他们又切到 ~ 下执行，这次还是因为目录非空失败。5. 这次他们打算
# rm -rf /mnt/data/postgresql/ 了，然后喜闻乐见的是， 删错机器了 ，他们删到正在运行的服务器上了。他们马上发现了这个错误并且把数据目录remount成ro避免进一步破坏。6. Matrix实例服务中止（Matrix不应该是去中心化的吗.webp），运维团队决定抛弃现有数据库，开始从冷备份里面开始恢复数据库。然而巨大的数据量+WAL replay消耗了相当长的时间。可喜可贺的是，整个服务还是正常恢复了。
Matrix.org 总结的教训
1. 别把数据库搞得那么大。 Synapse（Matrix.org的实现）正在实现这一点。
2. 增量备份弄的勤快一点，不至于有那么多 WAL Replay。
3. 不要用
db-01 db-02 这种容易混淆的命名。4. 不同服务器终端的背景颜色要明显不一样。
5. 用zfs做本地snapshot（在CoW上跑数据库吗？哈基米你这家伙。）
编者评价：其实挺不错的了，至少没丢，而且主要的不可用时间是因为数据传输导致的。（
https://www.youtube.com/watch?v=W42YJYkO8gw
https://matrix.org/blog/2025/10/post-mortem/
