MyDumper / MyLoader无法将大型表导入azure MySql数据库

Question

我正在将一个大型mysql数据库迁移到一个“Azure- database灵活服务器”。数据库中有几个大于1GB的表，其中最大的一个是200 1GB。所有的表都是InnoDB表。

由于表的大小，正常的mysql转储无法工作，因此，正如这里所建议的，我求助于MyDumper/MyLoader：https://learn.microsoft.com/en-us/azure/mysql/concepts-migrate-mydumper-myloader

我使用以下命令转储了一个大型表( 31GB表)：

mydumper --database mySchema \ 
         --tables-list my_large_table
         --host database
         --user root
         --ask-password
         --compress-protocol
         --chunk-filesize 500
         --verbose 3 
         --compress 
         --statement-size 104857600

然后，我将文件复制到与Azure数据库相同的区域/区域中的VM中，并使用以下命令启动导入：

myloader --directory mydumpdir \
         --host dbname.mysql.database.azure.com \
         --user my_admin \
         --queries-per-transaction 100 \
         --ask-password \
         --verbose 3  \
         --enable-binlog \
         --threads 4 \
         --overwrite-tables \
         --compress-protocol

MyLoader似乎开始加载并产生了以下输出：

** Message: 08:37:56.624: Server version reported as: 5.7.32-log
** Message: 08:37:56.674: Thread 1 restoring create database on `mySchema` from mySchema-schema-create.sql.gz
** Message: 08:37:56.711: Thread 2 restoring table `mySchema`.`my_large_table` from export-20220217-073020/mySchema.my_large_table-schema.sql.gz
** Message: 08:37:56.711: Dropping table or view (if exists) `mySchema`.`my_large_table`
** Message: 08:37:56.979: Creating table `mySchema`.`my_large_table` from export-20220217-073020/mySchema.my_large_table-schema.sql.gz
** Message: 08:37:57.348: Thread 2 restoring `mySchema`.`my_large_table` part 3 of 0 from mySchema.my_large_table.00003.sql.gz. Progress 1 of 26 .
** Message: 08:37:57.349: Thread 1 restoring `mySchema`.`my_large_table` part 0 of 0 from mySchema.my_large_table.00000.sql.gz. Progress 2 of 26 .
** Message: 08:37:57.349: Thread 4 restoring `mySchema`.`my_large_table` part 1 of 0 from mySchema.my_large_table.00001.sql.gz. Progress 3 of 26 .
** Message: 08:37:57.349: Thread 3 restoring `mySchema`.`my_large_table` part 2 of 0 from mySchema.my_large_table.00002.sql.gz. Progress 4 of 26 .

当我在Azure数据库上执行一个“显示完整进程列表”命令时，我看到了4个连接的线程，但我看到它们都在休眠，似乎什么都没有发生。

当我不关闭命令时，它会在很长一段时间后出错：

** (myloader:31323): CRITICAL **: 17:07:27.642: Error occours between lines: 6 and 1888321 on file mySchema.my_large_table.00002.sql.gz: Lost connection to MySQL server during query
** (myloader:31323): CRITICAL **: 17:07:27.642: Error occours between lines: 6 and 1888161 on file mySchema.my_large_table.00001.sql.gz: MySQL server has gone away
** (myloader:31323): CRITICAL **: 17:07:27.642: Error occours between lines: 6 and 1888353 on file mySchema.my_large_table.00003.sql.gz: Lost connection to MySQL server during query
** (myloader:31323): CRITICAL **: 17:07:27.642: Error occours between lines: 6 and 1888284 on file mySchema.my_large_table.00000.sql.gz: MySQL server has gone away

这些错误之后，表仍然是空的。

在卸载/加载时，我尝试了几种不同的设置，但都没有效果：

(100mb)

• remove --compress-protocol

• 只启动一个线程
• 使小块

我还尝试导入一个更小的表(400 in块为100 in )，设置完全相同，这实际上起作用了。

我试图将这些表导入到本地机器上的mysql数据库中，在那里我遇到了完全相同的问题:大型表(31 of )导入创建了4个休眠线程，没有做任何事情，而较小的表导入(100 my块中的400 my)确实有效。因此，这个问题似乎与Azure数据库无关。

我现在不知道问题出在哪里，有什么想法吗？

Answer 1

我也遇到了类似的问题，对我来说，结果是我恢复到的实例太小了，服务器一直没有内存。尝试将实例大小临时增大到更大的大小，一旦数据被导入，实例的大小就会缩小。