Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
It can be dangerous to run "set read_only" on a production server because it can block in close_cached_tables. More details about the pain this caused previously are at:
http://mysqlha.blogspot.com/2008/07/what-exactly-does-flush-tables-with.html
Per the code in set_var.cc:
/*
|
Perform a 'FLUSH TABLES WITH READ LOCK'.
|
This is a 3 step process:
|
- [1] lock_global_read_lock()
|
- [2] close_cached_tables()
|
- [3] make_global_read_lock_block_commit()
|
[1] prevents new connections from obtaining tables locked for write.
|
[2] waits until all existing connections close their tables.
|
[3] prevents transactions from being committed.
|
*/
|
Can there be a variant that doesn't do #2? My workload doesn't use MyISAM and I don't know if #2 is done because of MyISAM. Calling close_cached_tables seems like a heavy way to force LOCK TABLEs to be unlocked. Any long running queries will cause #2 to block.
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
We can skip incrementing refresh_version for the case of
set readonly=1
The reason we increment refresh_version is to ensure that we will close any old instances of the table and read the possible new table definition (that may have changed during FLUSH TABLES).
This is not needed when setting readonly.
Patch committed
http://lists.askmonty.org/pipermail/commits/2012-May/003284.html
New patch committed:
http://lists.askmonty.org/pipermail/commits/2012-May/003324.html
Will "refresh_version" still be incremented in this case? And if yes, then doesn't that create a significant performance impact by forcing all InnoDB table instances to be reopened?