这几年在存储上犯的错
这篇讲的是作者从亲身经历出发，分享这些年在存储和运维上踩过的真实大坑。文章从一起线上数据误删事件切入，没有说教，而是直接讲述了几个让作者“想死的心都有”的故障现场：比如用错误配置上线，瞬间拖垮了整个数据库集群；在恢复误删数据时，不慎将 DROP TABLE 命令也一并执行，导致只恢复出了一个豆列；以及在进行数据库主从切换时，因与同事短暂交谈分心，在从库同步未追平的情况下就进行了操作，最终引发数据冲突。 每个案例都像一部微型灾难片，详细描述了错误的决策瞬间、连锁反应以及在巨大精神压力下的补救过程。作者坦诚地剖析了背后的直接原因，例如对配置项的误解（SET GLOBAL SQL_LOG_BIN）、脚本操作的风险以及流程中的侥幸心理。 文章的结尾给出了沉痛而实用的教训：“备份不做，日子甭过”，并强调了任何危险操作都应确保可回滚，工具应该比人更可靠。它并非一篇技术方案，而是一面镜子，照见了运维工作中那些不可避免的“人为因素”，也体现了团队在危机中相互支持的宝贵文化。对于每一位需要和线上系统打交道的工程师，这都是一次难得的经验共情。
迁移到 Octopress
作者将用了三年的 WordPress 博客迁移到了 Octopress。主要动机是 WordPress 太过臃肿，仅几个 PHP-FPM 进程和 MySQL 就占用了约 400MB 内存，对于访问量不高的博客来说资源消耗很不划算。Octopress 作为一个静态发布系统，以其配置简单、原生支持 Markdown 语法、模板美观等优点，迅速吸引了作者。 迁移过程主要参考了 Octopress 官方文档和几篇社区文章，几个小时内便完成了数据导出、导入和部分文章的润色，一个全新的静态博客就基本可用。不过作者也指出了 Octopress 不够完美的地方，例如插件生态较少，甚至缺少标签云这类基础功能。在迁移中还遇到了一个具体坑：更换正式域名后，生成的静态页面和 RSS 中的 URL 会新旧随机变化，导致 IFTTT 误认为文章全部更新而向 Twitter 发送了大量重复信息。清除缓存目录后问题得以解决。 总的来说，Octopress 虽不完美，但已能很好地满足作者对轻量、高效博客系统的需求。