already be complete for transport by ssh. I still think scp is the more proper way to go.
dan orlic
Steve Williams wrote:
Hi,
We have a (pre-existing) disaster recovery/backup script that uses = mysqldump, ssh, mysql to backup an existing database. One of the tables = is rather large (1 Gig or so), and the time that it takes to "DROP = TABLE" on an already loaded recover server causes a timeout. I have = confirmed tested by creating an empty database on the recovery server & = the mysqldump loads fine. The second time I run it, it gets a timeout = error.
The basic logic is:
mysqldump ... somedatabase | ssh [EMAIL PROTECTED] "mysql ..."
This technique is because only the SSH port is open to the recovery = host.
mysqldump: Error 2013: Lost connection to MySQL server during query when = dumping table 'Item' at row: 1539
real 3:10.4 user 0.0 sys 0.0
I just do not know which timeout is causing the problem.
mysql> show variables like '%timeout%' -> ; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | connect_timeout | 5 | | delayed_insert_timeout | 300 | | innodb_lock_wait_timeout | 50 | | interactive_timeout | 28800 | | net_read_timeout | 30 | | net_write_timeout | 60 | | slave_net_timeout | 3600 | | wait_timeout | 28800 | +--------------------------+-------+ 8 rows in set (0.06 sec) =09
Or is it a timeout associated with mysqldump??
Can anyone shed some light??
Thanks, Steve Williams
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]