当前位置: 安卓之星 -> Linux开发 -> mysql日常这点事儿(8)之备份恢复基本原则

mysql日常这点事儿(8)之备份恢复基本原则

作者:网络 发表于: 2016-08-28 点击: 269 次

    经常会有人问,如何去备份海量数据呢?如何去做到每小时去备份TB级的数据呢?偶尔听到一些朋友说道,某次,还在做上一小时的mysqldump,这小时的任务又来了,怎么处理。我想,这里涉及到了一个海量备份的基本思路–仅备份改变的数据!这个很重要。
    从数据恢复的角度来说,对冷备份的恢复步骤是最简单的,简单的mv-cp,OK了。但实际上大多数线上业务,都会要求7*24不down机。如何解决呢?常见的方案:
    再配一台slave,专门用来备份。好了这时候,问题来了,如何备份呢?stop slave -》flush table with read lock -》mysqldump all database-》搞定。这个可能是大多数人做的方法。少量数据,备份与恢复都没啥问题。
    新的问题来了,海量数据如何处理呢?再进一步的备份方案,接着上面的,开始增量备份,打开binlog,备份binlog。增量出来了。数据备份量真的很少了。备份也很快了。
    下一个问题来了,如何处理高频率的备份呢?由高频率备份造成的恢复压力如何处理?我们都知道,增量备份的备份速度块,恢复速度慢,需要挨个应用备份的增量。解决思路:stop slave-》stop mysqld-》cp 数据文件、表定义。
    下一个问题,why我们需要备份这么多数据呢?myisam不存在太大的问题,你用哪个就备份哪个,INNODB呢?默认是共享表空间,你只能都备份了。处理下?在建库的时候就设定,file-per-table。OK,我们也能对innodb做改过哪个备份哪个的冷备份了。
    下一个问题,在电信计费数据库里,很常见的做法就是分开历史表,现状表,历史库,现状库,我们也可以把这个借鉴到mysql里面,由此,备份数据量,明显就减小了,备份速度也就能很快上来。

    再次强调下备份思路,仅备份改变的玩意,尽快将不改变的东西放到历史库里面去,减小备份压力。

    请仔细分析下业务需求,哪些数据需要做到日全备,时增量,而哪些数据只需要做到周全备,日增量,甚至月全备,周增量。这个很重要,备份策略的细分,能减低绝大部分不必要的资源消耗。

相关文章

相关文章

赶快留言冒泡

  • 评论 (0)
  • 引用通告 (0)
目前还没有任何评论.
目前还没有任何Trackbacks和Pingbacks.
吐个泡浮上去.