Debuging import of a large dump file to MySQL I'm trying to import a 50GB dump file to AWS RDS instance and have an issue. I get the following error:

ERROR 2013 (HY000) at line 15850: Lost connection to MySQL server during query


In the beaning i got this error after a few minutes, Then i increased the parameter max_allowed_packet to 1G. Now i get this error after 2.5 hours. What could be the issue? Is there any way to debug this issue? I couldn't find any relevant logs. 

Here are some of the relevant DB paramameters:

mysql&gt; SHOW VARIABLES like '%innodb_bu%';
+-------------------------------------+----------------+
| Variable_name                       | Value          |
+-------------------------------------+----------------+
| innodb_buffer_pool_dump_at_shutdown | OFF            |
| innodb_buffer_pool_dump_now         | OFF            |
| innodb_buffer_pool_filename         | ib_buffer_pool |
| innodb_buffer_pool_instances        | 8              |
| innodb_buffer_pool_load_abort       | OFF            |
| innodb_buffer_pool_load_at_startup  | OFF            |
| innodb_buffer_pool_load_now         | OFF            |
| innodb_buffer_pool_size             | 50503614464    |
+-------------------------------------+----------------+
8 rows in set (0.00 sec)

mysql&gt;  SHOW VARIABLES LIKE '%_timeout';
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 50       |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| rpl_stop_slave_timeout      | 31536000 |
| slave_net_timeout           | 3600     |
| wait_timeout                | 28800    |
+-----------------------------+----------+
12 rows in set (0.00 sec)

mysql&gt; SHOW VARIABLES like '%max_all%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| max_allowed_packet       | 1048576000 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+


Please advise.
There are two possibilities for this issue.


Wait timeout
Low resource on the server where you are trying to restore the DB.


Increase the lock_wait_timeout and wait_timeout to 300 seconds.
Try to restore the Database where you have enough resource to export the file(generally if you are using a t2.nano or t2.micro instances(where you are executing the restore command and keep the Backup file), then it'll kill the restore query due to low resource)