作者归档:17173系统部

[MySQL FAQ]系列 — 使用mysqldump备份时为什么要加上 -q 参数

mysqldump

写在前面:我们在使用mysqldump备份数据时,请一定记住要加上 -q 参数,后果可能是很严重的,不要给自己挖坑哦。到底为什么呢,且听我慢慢道来!

先来看看 mysqldump –help 中,关于 -q 参数的解释:

-q, --quick         Don't buffer query, dump directly to stdout.

简言之,就是说加上 -q 后,不会把SELECT出来的结果放在buffer中,而是直接dump到标准输出中,顶多只是buffer当前行结果,正常情况下是不会超过 max_allowed_packet 限制的,它默认情况下是开启的。

如果关闭该参数,则会把SELECT出来的结果放在本地buffer中,然后再输出给客户端,会消耗更多内存。

在mysqldump.c中也能看到二者的对比(现在流行深入源码,虽然我不是专注开发的,找几行源码能力还尚存,用来装B的,大家知道就好,哈哈):

if (quick)
  res=mysql_use_result(sock);
else
  res=mysql_store_result(sock);

有理论,也要有实践不是,我们来看看在实际场景中,加不加 -q 的区别有多大。

部分备份(启用-q) 部分备份(禁用-q) 完整备份(启用-q) 完整备份(禁用-q)
备份总耗时 27.882秒 22.665秒 277.387秒 217.074秒
占用内存(含swap) 3056KB 2.5GB 3048KB 内存:12GBswap:305MB

可以看到,如果只是备份小量数据,足以放在空闲内存buffer中的话,禁用 -q 会快一些,但如果是大数据集,没办法完全hold在内存buffer中时,就会产生swap,效率反而更差,真是赔了夫人又折兵。

因此,如果使用mysqldump来备份数据时,建议总是加上 -q 参数,避免发生swap反而影响备份效率。

详细过程(有耐心的可以继续往下看)

1、全量备份:备份时不使用 -q 参数

mysqldump --quick=false -Smysql.sock -B yejr --tables t_yejr

#先看下一开始时的状态:
Mem:  32863040k total, 29338704k used,  3524336k free,   227632k buffers
Swap: 16777208k total,    23548k used, 16753660k free,  8200416k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21986 root      20   0 6119m 5.9g 2192 S 20.6 18.9   0:21.69 mysqldump

#再看下备份结束后的状态,内存不够用,产生了swap
Mem:  32863040k total, 32521328k used,   341712k free,      440k buffers
Swap: 16777208k total,   336876k used, 16440332k free,   315192k cached
PID   USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+   COMMAND
21986 root      20   0 12.3g  12g  656 R 100.0 39.1   2:23.93 mysqldump

#最后看下备份总耗时
real    4m37.387s
user    2m2.731s
sys     0m24.608s

2、全量备份:备份时启用 -q 参数

mysqldump -Smysql.sock -B yejr --tables t_yejr

#先看下一开始时的状态:
Mem:  32863040k total, 20157476k used, 12705564k free,     4608k buffers
Swap: 16777208k total,        0k used, 16777208k free,   488296k cached

#再看下备份结束后,可以看到,没有使用到swap
Mem:  32863040k total, 32644496k used,   218544k free,      920k buffers
Swap: 16777208k total,        0k used, 16777208k free, 12618740k cached
PID   USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25234 root      20   0 50880 3048 2192 S 57.6  0.0   2:22.79 mysqldump

#最后看下总耗时统计:
real    3m37.074s
user    2m6.018s
sys     0m17.315s

3、部分备份:备份时不使用 -q 参数

mysqldump -w " id<100000 " -Smysql.sock --quick=false -Smysql.sock -B yejr --tables t_yejr

#看下总耗时
real 0m22.665s
user 0m20.458s
sys 0m2.156s

#再看下mysqldump进程消耗的内存,最高时大概使用了2.5G内存
20619 root      20   0 2571m 2.5g 2208 R 99.9  7.8   0:11.63 mysqldump

4、部分备份:备份时启用 -q 参数

mysqldump -w " id<100000 " -Smysql.sock -Smysql.sock -B yejr --tables t_yejr

#看下总耗时,并没有慢多少
real 0m27.882s
user 0m22.610s
sys 0m0.670s

#再看下mysqldump进程消耗的内存,只占用了极少量内存
19690 root      20   0 50880 3056 2200 S 73.4  0.0   0:06.01 mysqldump

MySQL出了门,Percona在左,MariaDB在右

MySQL vs Percona vs MariaDB

前言:作为没有自主研发能力的企业,MySQL、Percona、MariaDB到底该选择哪个?

今天看到SOHU-DBA公众号推送的文章:《MySQL分支的选择:Percona还是MariaDB》,原文出处:http://www.biaodianfu.com/mysql-percona-or-mariadb.html,这个文章比较长,有兴趣的可以找到原文看看,我也来简单说下我的看法。

就目前而言,我个人优先推荐使用Percona分支版本,它和官方版本相对是最近的,迁移切换的代价也很小。我从2008年开始就使用Percona分支版本到现在了,当初我们可是国内最大的Percona免费用户。最早只是在官方版本上打了一些补丁,现在已经发展形成了自己的XtraDB引擎,提供PXC高可用解决方案,并且附带了percona-toolkit等DBA管理工具箱,非常方便。

而MariaDB分支则做了较大改动,虽然也集成了XtraDB引擎的大多数优势,但从官方版本迁移过去,不确定因素等风险还是挺大的,比如GTID不兼容、查询优化器个别时候更糟糕等等,不过MariaDB还是挺值得期待的。

综上,建议先继续使用Percona分支,等MariaDB分支相对更成熟了再用不迟,对这两个分支都不感兴趣或不敢用的,再最后选择官方版本吧,把我上面的话当耳边风就行了,但我要告诉大家的是,在官方版本上能遇到奇葩的事情更多,尤其是查询优化器,快吐血了。