1. mydumper 的安装依赖于mysql软件，要使用mydumper 则服务器上必须先安装mysql
2. mydumper 安装时会使用mysql软件的动态链接库文件，如果服务器上mysql版本发生了变化，那么mydumper 也需要重新安装
3. 使用mydumper 最好为不同的数据库提供不同的账户，并且导入的时候，尽量要在本地导入，不进行远程操作；即使用 myloader -S 参数
这是因为mydumper 与myloader的命令格式非常相似，容易将mydumper 的-u -p -h -P信息一复制就粘贴到myloader中去了
mydumper -u mhiser -p 1r23kl456 -h 172.17.13.11 -P 3306 -e -t 8 -o /data/backup/full_20181210
这样做的结果就是将备份出来的数据又导回原库中，但原库是有业务写入的，这样库的数据就不正确了
4. myloader后的 -h 一定要写127.0.0.1，如果不是本地操作，要确定一下为什么要远程导入，确保导入的IP的正确性，一旦IP错误，则可能损坏数据；最好在导入前mysql -u测试一下这个链接
5. 通常情况下，一个库同一时间只能有一个mydumper导出进程运行，启动第二个时会报
** (mydumper:3128): CRITICAL **: There are queries in PROCESSLIST running longer than 60s, aborting dump,
use --long-query-guard to change the guard value, kill queries (--kill-long-queries) or use different server for dump
6. mydumper重复导出到相同的目录不影响文件的正确性。就是导出已经结束，但由于一些原因又重复执行了该导出命令（短时间 内），此时不要担心，去看备份文件的修改时间，mydumper只是更新了一些配置，并没有修改备份数据，备份依然是有效的。
7. mysqldump从PXC中导出数据时，会报以下错误，需要加--skip_add_locks --skip-lock-tables参数才行，就是不锁表导出；但mydumper则能正常导出数据，比如当数据量小，或者大到磁盘上无法存放备份的时候，可使用mydumper进行远程并发导出。
mysqldump: Got error: 1105: Percona-XtraDB-Cluster prohibits use of LOCK TABLE/FLUSH TABLE <table> WITH READ LOCK with pxc_strict_mode = ENFORCING when using LOCK TABLES
8. myloader导入时默认是不记录日志的，如果你导入的是主库，那么从库不会有变化，基于binlog日志的同步将全步失效，需要记录日志则需要添加-e, --enable-binlog 参数
9. 导出与导入的线程数最好一致，比如导出时使用的是8线程，导入最好也使用8线程
10. mydumper多线程导出的数据库文件，myloader无法导入到MGR架构中。现象为写入一段时间数据后就不再写入了myloader导入进程还在，卡在那里不动了。因此若是往mgr架构中导入数据，还是使用mysqldump比较保险。后来通过关闭MGR所有读节点，只保留一个写节点，解决了这个问题。
11. mysqlpump同样支持多线程，但它使用的前提是mysql版本5.7.8及以上（ Server version should be 5.7.8 or above）。
12. 数据库如果开启GTID，使用mydumper搭建GTID主从同步的时候，需要手工设置一下GTID的信息才可以同步
$ cat metadata Started dump at: 2019-02-20 17:37:23 SHOW MASTER STATUS: Log: mysql-bin.001545 Pos: 290649324 GTID:aaaaaaaa-bbba-ccca-ddda-aaaaaaaaa101:1-48661145
从库上的操作
reset master; SET @@GLOBAL.GTID_PURGED='aaaaaaaa-bbba-ccca-ddda-aaaaaaaaa101:1-48661145';
CHANGE MASTER TO MASTER_HOST='10.*.*.*',MASTER_PORT=3801,MASTER_USER='d******',MASTER_PASSWORD='d*******',MASTER_AUTO_POSITION=1; start slave; show slave statusG;
13. 支持远程操作。比如要备份一个库，不必在服务器本地做，完全可以在一台远程服务器上操作； 如果需要恢复，也可以在远程服务器上将数据导入回来。
场景一：故障恢复，库大小1T，磁盘大小也1T，所以不可能把备份数据落到本地再恢复，因为空间不够；
场景二：离线恢复，可以直接在远程的备份存储机上执行恢复命令，将数据恢复到一个库中；做成通用脚本，参数为库名、日期、IP与端口，执行脚本即可得到一个特定日期的数据库版本。
尽管如此，大数据量下还是少用远程操作，一次导入可能几个甚至几十个小时，网络波动一下，这次的导入可能就得重来了，为什么是可能呢，因为还要看导入工具是否支持类似“断点续传”的功能
14. 通常说mydumper不锁表，这句话在大多情况下正确，但千万不要理解成不会影响数据库的正常运行；曾经同时导出8套线上主库的数据到8个服务器上，都是高并发库，约十分钟后第6套主库的线程数就到了2000，处理时到了4000，一个500秒的update语句，大量的全局读锁，我杀了该库的导出进程，瞬间锁就降下来了
15. -B参数后只能写一个库名；如果一个实例有多个库，可以尝试正规匹配 --regex '^(?!(information_schema|mysql|sys|test|performance_schema))'
16. mydumper可以并发导出，但这种并发是以表为单位的。比如库中只有两个表，你设置三个线程是没有用的，因为一个表一个线程，最多只需要两个线程。也意味着最大的那张表决定了导出的时间长度。
17. mydumper -F 500这个参数很有用。单表100G，导出为一系列单个500M的文件，虽然在导出时无法做到并行导出，因为单表单线程；但在导入的时候，是可以做到多线程。如果只写入到一个文件中，那么导入的时候，也只能是单线程导入了。
18. mydumper --compress导出的文件以压缩格式存放，导入时不需要格式解压，直接导入即可