问题

    环境

    硬件：DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram

    软件：2.6.9-55.ELsmp x86_64, mysql 5.1.x

    现象

    2个库，其中1个业务库下有20多个表，表文件大小总量不到2G。

    另一个为日志库，下400多个表，大致是每天会产生5个表，其中有一个表较大，约400MB，总量约40多GB。

    每次备份耗时较长，最严重的一次花了5个多小时才完成。

    业务库为当前活动库，日志库则主要用作备份，每天日志归档，过期数据表很少有读写请求。

    InnoDB Buffer Pool总共分配了2G，从系统命令 top 结果来看，mysqld 只分配了 1.7G 内存，buffer pool 并没有全部耗尽。

    SHOW ENGINE INNODB STATUS 结果中也看到了，buffer pool 确实没用完，还有不少空闲的。

    备份时，观察 vmstat 结果，发现 bi 和 bo 的量较大，而且两个的值基本相当，备份其中一个表约 500MB，耗时 46 秒。

    按照这个耗时计算，全部备份出来也不需要5个多小时，这是为什么呢？

    分析

    大家先分析下，看是什么原因，稍后给出答案 :)

    原因 其实问题原因很简单，但一般人不容易想到。那就是，那些历史的日志表，由于长时间不读取，大部分数据没有在innodb buffer中。所以，每次备份时，大部分数据都要产生大量的物理读，然后再产生物理写，然而该服务器只有2块硬盘，I/O性能有限，所以备份非常慢。

    这时候，我们可以有几种解决办法：

    1. 删除过期日志表，或者放到线下的归档数据库上

    2. 如果innodb buffer还有大量空闲的话，可以不定期执行select * from table，将这部分数据load到buffer中，减少备份时的物理I/O，提高速度

建议继续学习：

1. 仅仅只备份是不够的    (阅读：4896)
2. 使用scp在windows和Linux之间互传文件    (阅读：4182)
3. rsync自动输入密码实现数据备份    (阅读：4082)
4. rman备份对各种数据块操作    (阅读：3686)
5. 使用 rsync 或 unison 备份或同步支持 ssh 的 web 主机    (阅读：3283)
6. mydumper的使用和源代码分析    (阅读：3168)
7. MySQL 备份和其恢复机制原理简述    (阅读：3131)
8. linux 定期自动备份mysql的shell    (阅读：3072)
9. 不可靠的EXP远程备份    (阅读：2778)
10. xtrabackup知多少    (阅读：2669)