Comment 1 for bug 803556

I also have a similar problem, with thousands of databases with almost a hundred tables each. In my case I can be sure no .frm changes during backup, but I still can't use --no-lock because I need binlog information to a) do point in time restore, and b) spawn slave instances.

The innobackupex script seems to spawn a cp processes for each (backing up to an nfs mount). So in addition to the time it takes to copy the files, it is spawning processes as well. There is a small optimization for scp when you use remote option, but only groups per db. The tar option also seems to spawn a tar process for each file.

It can take tens of minutes to finish, meanwhile the entire mysql is read locked.

I also discovered that the mysql slow log will not log any queries that have lock time due to the 'flush tables with read lock' unless slow log time is 0. It was quite a mystery to have a client show waiting for several minutes for a query and nothing show in the slow log.