mydumper适合库中有大表且CPU个数较多的场景，多用于恢复从库或单个实例
推荐用法
****************************
mydumper -u automng -p rootroot -h db48 -P 3309 -e -t 10 -r 5000000 -o /data/backup/full_20180928 &
其他示例
*******************************************
全库备份
mydumper -u automng -p Automng_123 -h 127.0.0.1 -P 3306 -o /data/backup/full_20180928 &
全库压缩备份，使用myloader恢复前需要先使用 gunzip 解压
mydumper -u automng -p Automng_123 -h 127.0.0.1 -P 3306 -c -o /data0/backup/full_20180928 &
全库压缩备份，-e 空表也生成一个文件，-t 线程数，若不指定-t则默认会启动四个线程
mydumper -u automng -p rootroot -h db48 -P 3309 -e -c -t 2 -o /data0/backup/full_20180928 &
-F 单个备份文件最大值大小，单位为M
mydumper -u automng -p rootroot -h db48 -P 3309 -e -c -t 10 -F 256 -o /data0/backup/full_20180928 &
-r 单个备份文件最多放300万条数据，个人测试的结果则是如果-r低于500万的话，则实际上是按500万条数据拆分的
mydumper -u automng -p rootroot -h db48 -P 3309 -e -c -t 10 -r 3000000 -o /data0/backup/full_20180928 &
备份指定库，没错，一次只能指定一个库
mydumper -u automng -p rootroot -h db48 -P 3309 -B diandidb -e -t 10 -o /data/backup/full_20180929 &
指定表
mydumper -u automng -p rootroot -h db48 -P 3309 -B vodb -T test -e -t 2 -o /data/backup/full_20180929
mydumper -u automng -p rootroot -h db48 -P 3309 -T vodb.test,diandidb.test -e -t 2 -o /data/backup/full_20180929
压缩比例
mydumper的压缩效果，如果数据高度不重复，比如sysbench生成的数据，则那么压缩比例大概在3：1左右；如果数据重复度高，比如我个人插入了1000万条“有张有驰有分寸+i”(i是从1至1000万的数字)，压缩比例为9：1
恢复示例
***************************************
myloader -u automng -p rootroot -h db48 -P 3309 -t 2 -o -d /data/backup/full_20180928 &
mydumper注意事项
**********************************************
在CPU充足的情况下，比如开启10线程时，mydumper的速度要远比mysqldump快；如果可用CPU数低于6的话，还是用mysqldump吧
mydumper可以拆分文件大小，不是所有数据库都写在一个文件中
在主从结构中，mydumper恢复时(不管是全库备份恢复，还是部分表的恢复)，从库没有变化，也就是说，从库并没有随着主库的恢复而恢复；注意，注意，此时的主从结构并没有被破坏，还具有主从同步的功能，只是主从数据库不一致了。
所在，在主从结构中，mydumper适合恢复从库，恢复后再次启动slave进程即可。那主库挂了怎么办？切从库