Dear All,
I am trying to restore a database of around 120G with maatkit (mk-parallel-restore). i know it is deprecated now but we were using mk for two years with no issue. All tables are successfulyl restored apart from one big table (25G).
I have tried to restore this one table many times but I get the error like followings all the time. Sometimes at sales_new.000032.sql.gz and sometimes sales_new.000037.sql.gz etc.
[root@mysqltest2 mysql]# mk-parallel-restore --user=root --ask-pass --nodisable-keys --verbose /backups/default/ --base-dir=/var/lib/mysql --databases=prodSales --tables=sales_new >> /tmp/restore.txt
Lost connection to MySQL server during query at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 800.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 801.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 802.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 803.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 804.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 805.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 806.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 807.
DBD::mysql::db commit failed: MySQL server has gone away at /usr/bin/mk-parallel-restore line 3056.
Issuing rollback() for database handle being DESTROY'd without explicit disconnect() at /usr/bin/mk-parallel-restore line 3358.
You have new mail in /var/spool/mail/root
I don't know what is causing this issue.
Some more information.
System: RHEL5.8, 64bit
mysql version: 4.1.22 && mysql-5.5
RAM: 16G
CPU: 2
xen virtual machines
[root@mysqltest1 ~]# ulimit
unlimited
[root@mysqltest2 ~]# ulimit
unlimited
i have tried alot to tune my configs to handle this but so far not able to restore successfully.
Here is my /etc/my.cnf for mysql-4.1.22
======
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
#max_connections = 300
skip-locking
key_buffer = 13000M
max_allowed_packet = 64M
table_cache = 16384
max_tmp_tables = 128
sort_buffer_size = 8M
read_buffer_size = 8M
myisam_sort_buffer_size = 128M
join_buffer_size = 128M
read_rnd_buffer_size = 128M
query_alloc_block_size = 32768
query_prealloc_size = 32768
thread_cache = 32
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
wait_timeout=31536000
========
Here is my /etc/my.cnf for mysql-5.5
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 12500M
max_allowed_packet = 64M
table_open_cache = 16384
sort_buffer_size = 8M
read_buffer_size = 8M
read_rnd_buffer_size = 128M
myisam_sort_buffer_size = 128M
thread_cache_size = 32
query_cache_size= 32M
wait_timeout=31536000
=====
After googling I have setup wait_timeout to 31536000 which I think doesnt work as whenever I check it from mysql its
mysql> show variables like '%wait_timeout%';
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| innodb_lock_wait_timeout | 50 |
| lock_wait_timeout | 31536000 |
| wait_timeout | 28800 |
+--------------------------+----------+
3 rows in set (0.00 sec)
mysql>
I have tried to restore this table on two different VMS with two different mysql versions (mysql-4.1.22 and mysql-5.5). The backup was done by mk-parallel-dump on mysql-4.1.22 production machine.
Any help would highly be appreciated.
Many thanks for your time.
Sam
I am trying to restore a database of around 120G with maatkit (mk-parallel-restore). i know it is deprecated now but we were using mk for two years with no issue. All tables are successfulyl restored apart from one big table (25G).
I have tried to restore this one table many times but I get the error like followings all the time. Sometimes at sales_new.000032.sql.gz and sometimes sales_new.000037.sql.gz etc.
[root@mysqltest2 mysql]# mk-parallel-restore --user=root --ask-pass --nodisable-keys --verbose /backups/default/ --base-dir=/var/lib/mysql --databases=prodSales --tables=sales_new >> /tmp/restore.txt
Lost connection to MySQL server during query at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 800.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 801.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 802.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 803.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 804.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 805.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 806.
MySQL server has gone away at line 3121 while restoring /backups/default/sales_new.000032.sql.gz at /usr/bin/mk-parallel-restore line 3124, <$fh> chunk 807.
DBD::mysql::db commit failed: MySQL server has gone away at /usr/bin/mk-parallel-restore line 3056.
Issuing rollback() for database handle being DESTROY'd without explicit disconnect() at /usr/bin/mk-parallel-restore line 3358.
You have new mail in /var/spool/mail/root
I don't know what is causing this issue.
Some more information.
System: RHEL5.8, 64bit
mysql version: 4.1.22 && mysql-5.5
RAM: 16G
CPU: 2
xen virtual machines
[root@mysqltest1 ~]# ulimit
unlimited
[root@mysqltest2 ~]# ulimit
unlimited
i have tried alot to tune my configs to handle this but so far not able to restore successfully.
Here is my /etc/my.cnf for mysql-4.1.22
======
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
#max_connections = 300
skip-locking
key_buffer = 13000M
max_allowed_packet = 64M
table_cache = 16384
max_tmp_tables = 128
sort_buffer_size = 8M
read_buffer_size = 8M
myisam_sort_buffer_size = 128M
join_buffer_size = 128M
read_rnd_buffer_size = 128M
query_alloc_block_size = 32768
query_prealloc_size = 32768
thread_cache = 32
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
wait_timeout=31536000
========
Here is my /etc/my.cnf for mysql-5.5
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 12500M
max_allowed_packet = 64M
table_open_cache = 16384
sort_buffer_size = 8M
read_buffer_size = 8M
read_rnd_buffer_size = 128M
myisam_sort_buffer_size = 128M
thread_cache_size = 32
query_cache_size= 32M
wait_timeout=31536000
=====
After googling I have setup wait_timeout to 31536000 which I think doesnt work as whenever I check it from mysql its
mysql> show variables like '%wait_timeout%';
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| innodb_lock_wait_timeout | 50 |
| lock_wait_timeout | 31536000 |
| wait_timeout | 28800 |
+--------------------------+----------+
3 rows in set (0.00 sec)
mysql>
I have tried to restore this table on two different VMS with two different mysql versions (mysql-4.1.22 and mysql-5.5). The backup was done by mk-parallel-dump on mysql-4.1.22 production machine.
Any help would highly be appreciated.
Many thanks for your time.
Sam