mydumper并行流备份调研

目的
         由于mysqldump工具是单线程备份，从备份效率来看，执行时间较长，效率非常低；从后续恢复使用来看，表级别的恢复需要使用专门的工具对数据拆分，工作量较大。第三方工具mydumper提供了并发备份功能，备份效率有很大提高，并且按照单表进行备份，表恢复工作方便。然而现有备份环境需要通过流方式，直接备份到备份服务器上，在本地不保留备份数据，而mydumper不支持流模式备份，基于该问题，对mydumper的源码进行分析和研究。
研究内容
问题1
mydumper在备份时，会不断读写metadata文件，该文件中存储了dump的操作时间信息。该文件的位置依赖于输入参数outputdir，即依赖于备份路径。如果使用流模式备份的话，会导致无法打开metadata而备份终止。
         具体细节参考代码部分，如下所示：

void start_dump(MYSQL *conn)
{
         ……
         if (daemon_mode)
                   p= g_strdup_printf("%s/%d/metadata", output_directory, dump_number);
         else
                   p= g_strdup_printf("%s/metadata", output_directory);
         FILE* mdfile=g_fopen(p,"w");

         为了去除mydumper备份对metadata的依赖，增加一个metadatadir参数，将metadata文件单独存放，这样数据文件的流备份就不会受到影响。基于这个思路，在输入选项中增加metadatadir参数，指定metadata的路径。
         修改代码如下所示：
1、增加metadata_directory变量

gchar *output_directory= NULL;
gchar * metadata_directory = NULL;

2、增加metadatadir参数

{ "outputdir", 'o', 0, G_OPTION_ARG_FILENAME, &output_directory, "Directory to output files to",  NULL },
{ "metadatadir", 'o', 0, G_OPTION_ARG_FILENAME, &metadata_directory, "Directory to metadata files to",  NULL },
{ "statement-size", 's', 0, G_OPTION_ARG_INT, &statement_size, "Attempted size of INSERT statement in bytes, default 1000000", NULL},

3、修改metadata文件完整文件名

void start_dump(MYSQL *conn)
{
         ……
         if (daemon_mode)
                   p= g_strdup_printf("%s/%d/metadata", metadata_directory, dump_number);
         else
                   p= g_strdup_printf("%s/metadata", metadata_directory);
         FILE* mdfile=g_fopen(p,"w");

         通过以上修改，将备份数据文件对metadata的依赖消除。
问题2
         mydumper是并行备份的，备份过程中，如何处理并发流向目的服务器，是一个难点。由于xtrabackup备份支持并行备份，且支持流备份。因此，基于这个思路，对xtrabackup的源码实现进行分析。
         源码分析发现，xtrabackup的并发处理只针对本地化存储，没有并发流备份到目的服务器的过程。如果是mydumper支持并发流处理，需要对mydumper的读写策略进行较大的修改，使其支持并发备份、压缩以数据流的方式传到服务器端。
从技术角度来说，通过查看相关资料，并发流处理是一个相对困难的问题。为了解决该问题，有两种思路：
1、建立网络通信，通过socket并行传输的方式实现将压缩后的数据并发备份到目的服务器。该方法从实现角度，需要在目的服务器编写客户端程序，用于接收和存储数据备份。而在实际应用工作中，往往直接调用hadoop来实现数据备份的传输。因此该思路更通用，但是在当前工作场景中，不适合。
         2、调用hadoop的系统命令，将压缩后的备份数据并发备份到目的服务器。该方法仅适合通过hadoop实现数据备份传输的场景。
         mydumper并行备份的并发流向目的服务器问题的解决采用第二种思路进行。通过改造，实现mydumper取代mysqldump逻辑备份，适合当前备份场景，提高备份和恢复的效率，减少备份和恢复的时间。
结论
         通过调研mydumper源码，针对存在的两个问题进行分析和探索。其中对第一个问题解决较简单，通过修改metadata路径，可以解除依赖关系。而对于第二个问题，经调研xtrabackup的并行处理只针对本地处理，不能满足当前应用场景，基于分析和研究，有两种解决思路，最终选择适合当前应用场景，通过调用hadoop系统命令的方式，解决mydumper的并行流备份问题。
         以上调研工作，仅代表个人观点和思路，欢迎相关专业人员交流和支持，解决mydumper的并行流备份问题。