Two Ideas for Wanmei’s Databases

一、利用filesystem snapshot备份数据

假设我们需要一小时备份一次数据库,假设我们的硬盘顺序写入速度平均大约是20MB/s,那么每小时最多也就能写入20*3600=72G的数据。假设我们的备份工具就是cp,那么算上读所需的时间,实际上当数据库的大小大于40G的时候,要想达成一小时一次的备份频率就很吃力了。此时还很重要的一点是,我忽略了这是一个正在使用的数据库,我假设这个数据库使用过程中因业务需要也是会产生IO的。而备份所产生的大量IO会导致数据库处理效率大大降低。

看mysql是如何处理这个问题的? flush logs to disk, then backup the binlogs (except the newest one)。我提过,被否了。我今年有空了我一定会自己写个简单的数据库练手完,我一定会实现这个功能的。然后我当时想过用zfs的snapshot解决这个问题,但是基于运营部门人手缺乏,让他们去熟悉freebsd、solaris然后把咱们的一部分系统迁上去那是完全不可能的。前一段时间因为meego的缘故我知道了btrfs,如果它能稳定下来,这是极好的选择,其次就是lvm的snapshot。总之无论用哪一种,都能大大降低硬盘负荷(减少硬盘损坏的概率且降低对服务的影响),并且减少硬盘占用。

另外,做版本回退也容易多了。如果服务器更新之后发现有BUG,可以在1分钟内回退到上个版本的代码和数据。

二、更改数据序列化规则,做成前后兼容的。

假如使用google protocol-buffer这样的东西去序列化数据,就可去掉因为数据库升级而更新表结构所花的时间,从而降低服务中断时间。完美不必去用google的东西,只需要稍微更改下现在的序列化/反序列化规则就可以了。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥