Bug #17017 can lock the database in order to build a tar archive
Submitted: 1 Feb 2006 17:27 Modified: 1 Feb 2006 20:51
Reporter: jmax reymond Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:4.1 OS:Linux (Linux debian)
Assigned to: CPU Architecture:Any

[1 Feb 2006 17:27] jmax reymond
Description:
in order to setup my replication, I want to backup the data repository after locking the database.
So, in another console, I lock with  FLUSH TABLES WITH READ LOCK;  but unfortunatly, tar reports an error because data/ibdata1 has changed during the processing of the tar command.
So, it appears that  FLUSH TABLES WITH READ LOCK;  does not really lock the database.
If I shutdown the master to have a safety save, I lost the information of the master status and later on the slave,  I cannot change the master host to  'master'  because when I start again the master, the position and the file have changed. 
data/ibdata1 seems used for innodb tables but how to lock innodb stuff ?

How to repeat:
in a mysql session, type 
 FLUSH TABLES WITH READ LOCK; 
in another session, type tar zcvf mydata.tgz data  
when processing data/ibdata1, you have an error message from tar saying that the file has changed during operation.
of course, database is in production !

Suggested fix:
method to really block the database ?
[1 Feb 2006 17:29] jmax reymond
exact version is 4.1.8 and the database is a mixed set of isam and innodb tables
[1 Feb 2006 20:51] MySQL Verification Team
We're sorry, but the bug system is not the appropriate forum for 
asking help on using MySQL products. Your problem is not the result 
of a bug.

Support on using our products is available both free in our forums
at http://forums.mysql.com and for a reasonable fee direct from our
skilled support engineers at http://www.mysql.com/support/

Thank you for your interest in MySQL.