my19_mysql 多线程备份恢复工具mydumper

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进程即可。那主库挂了怎么办？切从库