Filip Krejci wrote:
Hi,
you are right, option --single-transaction does not accquire any lock on
your innodb tables. Backup is fully on-line due to mvcc.
You should look for another reason of this behavior.
1/ What says 'show full processlist' when backup is running
It shows mostly inserts/updates into tables, these tables being tables
other then the huge 16-17 million row one. These tables are used for
session storage, and as such, if this block (which goes on as almost the
first thing my site does), then no SELECT statements for site content
are executed....
2/ What says 'show engine innodb\G' when backup is running
I've actually not checked - I shall do that and report shortly - it's
nearly midday for me, and that means lots of traffic on the site, not a
good time to be playing :)
2/ Is your db server stopped or very slow only? (you will see in 1/)
I *think* it's slow to the point where it's unusable. Until the backup
gets round to the huge table, inserts/updates/selects are all going on
just fine,.
3/ If it's very slow
a/ what is your mysqldump config in my.cnf
[mysqldump]
quick
max_allowed_packet = 16M
that's all there is... I'm not sure what hte 'quick' does, I'll go and
check the manual on that, perhaps that's the issue. I'm guessing I
might have more luck increasing the packet size?
b/ what about remote backup (mysqldump --host x.x.x.x --master-data
--single-transaction > dump.sql) which cause separating writes on
another box?
I did do this under the assumption it could simply be an I/O problem -
however the problem persists. It might be because the network
connection between the two hosts is pretty fast
Thanks Filip!
--
Ian P. Christian ~ http://pookey.co.uk
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
