Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2909756
  • 博文数量: 199
  • 博客积分: 1400
  • 博客等级: 上尉
  • 技术积分: 4126
  • 用 户 组: 普通用户
  • 注册时间: 2008-07-06 19:06
个人简介

半个PostgreSQL DBA,热衷于数据库相关的技术。我的ppt分享https://pan.baidu.com/s/1eRQsdAa https://github.com/chenhuajun https://chenhuajun.github.io

文章分类

全部博文(199)

文章存档

2020年(5)

2019年(1)

2018年(12)

2017年(23)

2016年(43)

2015年(51)

2014年(27)

2013年(21)

2011年(1)

2010年(4)

2009年(5)

2008年(6)

分类: Mysql/postgreSQL

2017-02-15 10:23:00

2017年1月31日GitLab.com发生的严重生成故障,导致宕机18小时,永久丢失6小时数据。
事后官方对故障原因作出了详细的解释,如下




这个事件,作为反例非常有借鉴意义。

通用的启示:
1. 定时检查备份的有效性。
2. 在成功创建一个更新的备份前,禁止删除当前最新的备份。
3. 危险操作包装成脚本,在脚本里执行危险操作前做好所有的必要检查。
4. 告警机制要能在无告警的情况下证明告警检查在正常工作。

PostgreSQL运维的启示:
要在主备部署上避免由于主库删除尚未拷贝到备库的WAL导致流复制中断。具体可以采用下面几个办法
1. 创建并保留WAL归档
   高负载的系统,归档WAL会占用空间大,代价比较高
2. 设置比较大的wal_keep_segments,在主库上保留足够的WAL
  wal_keep_segments建议至少设1000(16GB),还需要考虑系统负载,库大小,比如参考以下的公式(不要问为什么,拍脑袋想的)。
  1. max(16GB,2*shared_buffer,0.1*数据总大小)/16MB
3. 使用slot复制,未被备机取走的WAL将一直保存在主机上。
   备库宕时,要及时在主库删除slot,否则主库的磁盘会被WAL撑爆,因此应辅助以磁盘的容量监控。



阅读(6705) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

babyyellow2017-02-28 14:57:45

这个问题, 本身不是问题, 是运维的问题.

作为一家公司, 没有合理的检查,复核机制. 


只能说他们的dba  吃翔去吧.