I'm not certain if this belongs in the InnoDB forum or Administration etc.
Since about MySQL 5.6.10 I routinely use "flush tables tablename, tablename... FOR EXPORT" to do filecopy backups of file_per_table InnoDB tables. This has been working fine. (prior to 5.6.10 it frequently caused fatal forever-locks)
Accidentally, I executed the flush WITH READ LOCK instead of FOR EXPORT. To my astonishment, it worked fine, writing a tablename.cfg file. Various subsequent tests show this "always" works, and the copied tablespace can be successfully imported using the cfg file. I have not yet found this behavior documented anywhere, nor any forum posts referring it.
Tested on both 5.6.13 and 5.6.14 64-bit, on Windows 7 64-bit, identical behavior.
Am I crazy? I can't believe this worked, and that the behavior is not documented. Is it intentional? Will FOR EXPORT be deprecated?
Since about MySQL 5.6.10 I routinely use "flush tables tablename, tablename... FOR EXPORT" to do filecopy backups of file_per_table InnoDB tables. This has been working fine. (prior to 5.6.10 it frequently caused fatal forever-locks)
Accidentally, I executed the flush WITH READ LOCK instead of FOR EXPORT. To my astonishment, it worked fine, writing a tablename.cfg file. Various subsequent tests show this "always" works, and the copied tablespace can be successfully imported using the cfg file. I have not yet found this behavior documented anywhere, nor any forum posts referring it.
Tested on both 5.6.13 and 5.6.14 64-bit, on Windows 7 64-bit, identical behavior.
Am I crazy? I can't believe this worked, and that the behavior is not documented. Is it intentional? Will FOR EXPORT be deprecated?