数据库升级前,先准备一份能真的执行的回滚清单
· 阅读需 3 分钟
数据库升级这种事,很多团队会认真写升级步骤,却不认真写回滚步骤。可真正到了线上,最能决定你心态的往往不是“怎么升”,而是“如果升坏了,能不能稳稳退回来”。
数据库升级这种事,很多团队会认真写升级步骤,却不认真写回滚步骤。可真正到了线上,最能决定你心态的往往不是“怎么升”,而是“如果升坏了,能不能稳稳退回来”。
带坐标的数据一多,最常见的需求之一就是“按距离最近排序”。
很多人一开始会先把经纬度查出来,再在应用层自己算距离、自己排序。小数据量时确实能跑,但 2016 年我在看这类场景时越来越觉得,所有距离计算都堆在应用层,其实是在主动放弃数据库已经能帮你做的一部分工作。
MongoDB 副本集这套能力刚接触时,很容易给人一种“数据已经更安全了”的感觉。这个判断不算错,但如果进一步把它理解成“那就等于已经做好备份了”,问题就会变得很严重。2014 年我在看一些 MongoDB 部署经验时,越来越觉得这两个概念必须尽早分开。
2014 年做内容站和后台系统时,MongoDB 很吸引人,原因很简单:模型灵活、起步轻、开发速度快。可一旦列表页慢下来,很多团队的第一反应都是“是不是该上副本集”“是不是该多加几台机器”。我后来发现,这种反应往往太快了。