I once had a project with one MySQL table that had over 2 million rows. First time I tried moving that project from one computer to another I had the error “ERROR 2006 (HY000) at line ###: MySQL server has gone away” come out while restoring the backup. After a LOT of research on the internet my coworker and I found out that the problem was that mysqldump was creating extremelly long insert sentences for that huge table.
To solve this problem we used the --skip-extended-insert option of mysqldump. The drawbacks of this option are that the dumps are much larger and that restoring those backups take longer. You can see in this post of High Availability MySQL blog some benchmarks done with and without --skip-extended-insert and how a normal dump for 16M rows would take around 170 seconds whereas this workaround would take around 1,100 seconds. Almost 7 times more.
Remember that --opt is used by default in mysqldump and it stands for:
--add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset
Thats the reason we use --skip-extended-insert to override the default --extended-insert behaviour.
There is also another approach increasing the max_allowed_packet I haven’t still tried. You can read more about it in the ref link down bellow.
Image may be NSFW.
Clik here to view.
Ref: http://dba.stackexchange.com/questions/5292/mysql-server-has-gone-away-obstructing-import-of-large-dumps
http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html
