2017年1月31日GitLab.com发生的严重生成故障,导致宕机18小时,永久丢失6小时数据。
误删 300G,GitLab 官方对删库事故的事后分析
这个事件,作为反例非常有借鉴意义。
通用的启示:
1. 定时检查备份的有效性。
2. 在成功创建一个更新的备份前,禁止删除当前最新的备份。
3. 危险操作包装成脚本,在脚本里执行危险操作前做好所有的必要检查。
4. 告警机制要能在无告警的情况下证明告警检查在正常工作。
PostgreSQL运维的启示:
要在主备部署上避免由于主库删除尚未拷贝到备库的WAL导致流复制中断。具体可以采用下面几个办法
1. 创建并保留WAL归档
高负载的系统,归档WAL会占用空间大,代价比较高
2. 设置比较大的wal_keep_segments,在主库上保留足够的WAL
wal_keep_segments建议至少设1000(16GB),还需要考虑系统负载,库大小,比如 参考以下的公式(不要问为什么,拍脑袋想的)。
3. 使用slot复制,未被备机取走的WAL将一直保存在主机上。
备库宕时,要及时在主库删除slot,否则主库的磁盘会被WAL撑爆,因此应辅助以磁盘的 容量监控。
事后官方对故障原因作出了详细的解释,如下
误删 300G,GitLab 官方对删库事故的事后分析
这个事件,作为反例非常有借鉴意义。
通用的启示:
1. 定时检查备份的有效性。
2. 在成功创建一个更新的备份前,禁止删除当前最新的备份。
3. 危险操作包装成脚本,在脚本里执行危险操作前做好所有的必要检查。
4. 告警机制要能在无告警的情况下证明告警检查在正常工作。
PostgreSQL运维的启示:
要在主备部署上避免由于主库删除尚未拷贝到备库的WAL导致流复制中断。具体可以采用下面几个办法
1. 创建并保留WAL归档
高负载的系统,归档WAL会占用空间大,代价比较高
2. 设置比较大的wal_keep_segments,在主库上保留足够的WAL
wal_keep_segments建议至少设1000(16GB),还需要考虑系统负载,库大小,比如 参考以下的公式(不要问为什么,拍脑袋想的)。
- max(16GB,2*shared_buffer,0.1*数据总大小)/16MB
备库宕时,要及时在主库删除slot,否则主库的磁盘会被WAL撑爆,因此应辅助以磁盘的 容量监控。