Comment 1 for bug 1100141
Revision history for this message
| Raghavendra D Prabhu (raghavendra-prabhu) wrote | #1 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
The problem with using a flush-time is that there is no way to
prevent newer queries from starting (unless there is a write lock
on all tables or something like that). So, it is possible that
innobackupex will wait forever. It is also not possible to do "It
will poll the process list and once there is no actively running
queries it will issue the FTWRL." since it is possible that in
time between polls another query has sneaked in.
FTWRL ensures a barrier of sorts in that all the queries after
that (if FTWRL is waiting on 'waiting for table flush') will
queue up in FIFO and will complete after FTWRL (so only queries
will complete, the writes/updates will still wait).
What can/may be done (as the last paragraph of description suggests) is for FTWRL to be run and if it is waiting too long for table flush (due to bug or bad queries), is to kill said queries after a configurable timeout. But this can be unsafe too. Note that this won't be subject to race conditions like earlier since MySQL ensures that queries after FTWRL are in queue after that.