A 业务日增 1500W 数据,采用 MySQL 分区存储。该分区表按照时间分区,每天一个分区。随着时间的推移,单表数据越来越多,占用空间越来越大,由此带来如下的不便:第一,单机磁盘容量有限,需要定期清理历史数据;第二,MySQL 对子查询、复杂查询支持不友好,在庞大的数据量下性能急剧下降,导致前端报表得出结果延时。为了永久存储数据,并且提升查询性能,便有了如下的技术方案选型。确定一个方案是否可行,有很多维度,比如:读写性能、数据可用性、改造成本、场景匹配度、机器成本、运维成本、系统容错性、高可用能力、横向扩展能力等等。重要的一点是,给出的测试报告要用数据说服别人,其中测试的维度设计就是需要下功夫的地方。由于应用场景复杂多变,很难找到一个通用的解决方案。某一个解决方案只能无限趋近特定的需求,某些功能很有可能需要定制。也就是说,一个大数据团队的研发能力也就决定了对业务需求的掌控能力。

Read more...


互联网的诞生和蓬勃发展,让信息流动变得无与伦比地便捷。古时飞鸽传书,千里马加急,爱人等待的煎熬与苦楚,君臣等待的焦急和惶恐,我们再也无法亲身体会。飞鸽可能半路失踪,千里马可能中途搁浅,剩下的只有无尽的叹息。然而,互联网让两个人的距离,只有 Enter 键那么远。我们生在一个巨大技术变革的时代,这是我们的幸运,也是我们的悲哀。本篇文章浅谈了信息的便利性、信息的用途、获取信息的途径、信息的准确性、信息与人的关系、信息的不对称,最后点明文章主旨,信息的边界。每段都相对较短,简洁明了的表明观点,不需要长篇大论。

Read more...


从 2015 年开始,笔者就很少去参加技术分享了。一方面,工作确实很忙,空闲时间又有一大堆事情要做;另一方面,参加这类技术分享的时间成本太高,收益太少。不过,本次由离线空间主办的线下活动,期待已久,个人认为这类分享很值得一去,因为你可以认识很多不同行业背景的人,他们有趣,往往会给你带来很多好玩、新鲜、很酷、高级的东西,对你的认知升级有很好的启发。找到沉迷的事情,热情投入、执着坚持、享受其中,这是人生最大的乐趣。

Read more...


根据莫非定律:「凡是可能出错的事必定会出错,任何一个事件,只要具有大于零的机率,就不能够确定它不会发生。」这句看似箴言的话,想必每个运维从业人员感触非常深刻。本文从 DBA 线上操作的角度,谈谈自己的看法。第一,处理工单、凌晨维护、处理紧急故障之前,梳理流程,准备必要的资料。第二,处理故障之前分析最重要。第三,学会沟通,尽可能地达到信息对称。第四,任何操作三思而后行。第五,事后 Review、反思、总结,形成知识库。软实力靠的是长期的积累,需要自控力不断提高。归根结底,任何管理本质上都是对自我的管理。

Read more...


某项目研发 A 删除压测环境大表,等待时间较长,于是直接将 MySQL 数据目录中对应数据库文件删除。于此同时,误删 ibdata 和 MySQL 配置文件。此时 MySQL 已经崩溃,研发从其他机器拷贝误删的数据文件以及配置文件,重启 MySQL,出现 Unknown/unsupported storage engine: InnoDB 错误,于是有了接下来的数据恢复。本文会从几个方面讲解这个案例,方案确定、方案实施、原理探讨和案例小结,期间会交代诸多细节,以及使用到的技巧。相信读者读完之后,会对以后的数据恢复有所启发。接下来,做如下总结:第一,备份重于一切。第二,遇到问题,恐惧问题比问题本身可怕。第三,解决问题的同时,做好素材收集很重要。第四,官方文档是一手好资料,应该好好利用。

Read more...