共计 3639 个字符，预计需要花费 10 分钟才能阅读完成。
作 者：李淳竹（lichunzhu），TiDB 研发工程师。
Migrate SIG Community，次要涵盖 TiDB 数据处理工具，蕴含 TiDB 数据备份 / 导入导出，TiDB 数据变更捕捉，其余数据库数据迁徙至 TiDB 等。
前言
Dumpling 是由 Go 语言编写的用于对数据库进行数据导出的工具。目前反对 MySQL 协定的数据库，并且针对 TiDB 的个性进行了优化。在 Go Dumpling! 让导出数据更容易 中，咱们简要介绍了 Dumpling 的基本功能的应用。在本文中，咱们将会介绍一些 Dumpling 的进阶应用办法，帮忙大家更稳固高效地导出数据。
导出到云盘
Dumpling 曾经在 v4.0.9 反对间接导出数据到 Amazon S3 云盘，仅需将 -o 参数指定为 “s3://${Bucket}/${Folder}” 并在环境变量中配置 AWS 密钥即可。而 Dumpling 的读写并行的设计也能够缩小导出到云盘时的性能损失。在测试中咱们将 dumpling 运行在 AWS pod 中，开启多线程后 dumpling 导出速度能够达到 420MB/s。
更多具体应用配置参考应用文档。
导出为压缩文件
Dumpling 曾经在 v4.0.9 中反对设置 --compress gz 将导出的 sql 文件压缩为 gz 格局，进步空间利用率，同时在上传云盘时也能够节俭网络开销与存储老本。在咱们的理论测试中，压缩为 gz 格局能够比间接导出 sql 格式文件节俭一半以上的空间。
更多具体应用配置参考应用文档。
更欠缺的提醒统计信息
在之前的应用过程中，有用户反馈在导出中 Dumpling 的提示信息有余，不能很好地理解 Dumpling 目前的导出状态。为此 Dumpling 在 v4.0.9 引入了更欠缺的信息提醒机制。示例如下：
[2020/11/17 20:23:55.526 +08:00] [INFO] [collector.go:211] ["backup Success summary: total backup ranges: 45970, total success: 45970, total failed: 0, total take(backup time): 30m50.068578882s, total take(real time): 31m4.41078434s, total size(MB): 1797708.77, avg speed(MB/s): 971.70, total rows: 9200295024"] ["split chunk"=13.484064398s]在导出工作完结后，Dumpling 会在 task summary 中显示本次导出过程的总共耗时，导出划分的 chunks，导出文件大小与 Dumpling 导出过程的平均速度等统计信息。
# HELP dumpling_dump_finished_rows counter for dumpling finished rows
# TYPE dumpling_dump_finished_rows counter
dumpling_dump_finished_rows 1.419506e+06
# HELP dumpling_dump_finished_size counter for dumpling finished file size
# TYPE dumpling_dump_finished_size counter
dumpling_dump_finished_size 2.92577519e+08在导出过程中，Dumpling 所用端口的 /metrics 地址也能够实时查问到 dumpling 目前已导出的行数与数据大小。
Dumpling 将会始终聆听社区声音并继续改良。如果大家有更多改良意见，也欢送大家到 Dumpling repo 提出 issue 与奉献 PR。
更欠缺的重试机制
在 v4.0.9 中，针对大数据导出的场景，Dumpling 退出了一系列重试机制来保障导出过程可能尽量排除网络稳定的影响而顺利进行上来。次要蕴含了两个方面的重试机制：
- 在上传数据到云盘时进行重试
Dumpling 向云盘服务器发送数据很容易因为网络稳定导致传输失败。Dumpling 通过为传输 client 设置正当的参数来重试传输数据的 HTTP 申请。通常状况下 Dumpling 会对可重试的谬误尝试发送数据 3 次，每次重试间会有逐渐减少并引入抖动的期待距离。
-
在数据库连贯中断时进行重试
在导出数据时数据库连贯可能会不可避免地受到稳定而中断。这时 Dumpling 会通过重建数据库连贯的形式来尽量保障导出过程持续进行上来。
这也会引出一个问题，Dumpling 提供了不同的一致性选项，贸然重建数据库连贯将可能毁坏导出快照的一致性。因而，Dumpling 针对不同的一致性配置做了不同的解决：
- consistency 为
snapshot或none：这两种状况中，Dumpling 并没有为数据库上锁，Dumpling 会间接重建数据库连贯。
- consistency 为
lock或flush：这两种状况中，如果导出数据较大心愿 Dumpling 能够重试，用户能够设置
--transactional-consistency=false配置 Dumpling 在整个导出过程中持锁。这时如果产生 Dumpling 数据库连贯中断的状况，Dumpling 将会首先查看锁数据库连贯是否依然工作失常，如果依然失常 Dumpling 将会重建数据库连贯使导出持续进行上来。
- consistency 为
反对管制导出时的零碎变量
Dumpling 反对了通过 –params 参数设置导出数据库时 session 变量，配置格局为 “character_set_client=latin1,character_set_connection=latin1″。用户能够通过一系列配置参数来实现不同的导出场景：
- 设置导出字符集
能够配置
--params "character_set_client=latin1,character_set_connection=latin1,character_set_results=latin1”管制导出字符集为 latin1 - 数据库导出内存管制
配置
--params "tidb_distsql_scan_concurrency=5,tidb_mem_quota_query=8589934592"缩小 TiDB 导出时 scan 数据并发度与语句内存应用，从而缩小 TiDB 导出时的内存应用 - 数据库低速导出
配置
--params "tidb-force-priority=LOW_PRIORITY,tidb_distsql_scan_concurrency=5"能够调低导出语句执行优先级并缩小 TiDB 导出时 scan 数据并发度，从而实现对数据库低影响的低速备份数据。下面参数列举了一些简略的
--params应用场景。也欢送大家开发出更多的应用场景，并向其余的社区小伙伴分享 Dumpling 的应用教训。
Dumpling 后续开发计划
以下为 Dumpling 后续开发的一些打算与构想，也欢送大家在 Dumpling Repo 一起交换探讨，参加开发。让咱们一起让导出数据更加容易！
- 反对并行导出 cluster index 的数据 (issue#75)
目前 Mydumper 和 Dumpling 都能够通过指定
rows参数开启表内并发，从而优化导出单个大数据表时的导出效率。它们的划分形式都是将表依照表的整数主键的从最小到最大划分为 count/rows 个区块再导出，然而这样的形式在数据的主键比拟扩散时导出成果会很差。尤其是 TiDB 4.0 后，开启了 auto-random 的数据表的主键将会更加离散，这势必引起数据块散布不平均从而影响导出效率。同时 TiDB 反对了 cluster index 参数而缩小回表次数，进步 TiDB 查问数据的效率，但该参数开启后 TiDB 可能会没有整数主键导致 Dumpling 无奈划分并发导出的区块从而升高导出速率。在探讨后，相比上版本咱们采纳了更加精细而精确的设计，即 TiDB 提供 TABLE SAMPLE 语句作为 Dumpling 划分区块的根据。该性能实现后，Dumpling 导出 TiDB 数据库的速度将会进一步晋升。
- 反对 TiDB 规范错误码 (issue#176)
Dumpling 打算反对 TiDB 规范错误码，能够不便 Dumpling 进行更精密的错误处理，也有利于用户依据错误码与提示信息找到导出问题并进行修改。
- 反对导出更多品种的源数据库 (issue#11)
一般来说，只有须要反对的数据库有对应的 database driver 或 client，比方 Oracle 数据库的 golang driver godror，咱们都能够轻微革新导出语句和调用的 Go 代码库后就实现该数据库的导出反对。这里也欢送社区的小伙伴们参加，帮忙 Dumpling 反对导出更多类型的数据库。
联 系：channel #sig-migrate in the tidbcommunity slack workspace, you can join this channel through this invitation link。
