Uploaded image for project: 'Percona XtraBackup'
  1. Percona XtraBackup
  2. PXB-1197

LP #1100141: FTWRL should only run when safe to do so


    • Type: Bug
    • Status: Done
    • Priority: Low
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None


      **Reported in Launchpad by Ryan Huddleston last update 17-01-2013 08:59:44

      Flush tables with read lock can run even though there may be an running query that has been executing for hours. In this case everything will be locked up in "Waiting for table flush" or "Waiting for master to send event" states. Killing the "flush tables with read lock" does not correct the issue either. In this case the only way to get the server operating normally again is to kill off the long running selects that blocked it to begin with.

      With the above in mind we should make FTWRL safer to prevent production downtime. To do this I suggest the following:

      flush-time that innobackupex will wait before issuing a FTWRL, (default 1800 seconds? configurable), during this time innobackupex will wait for running processes to finish. It will poll the process list and once there is no actively running queries it will issue the FTWRL. If --rsync option is set is still should run rsync prior to the FTWRL.

      Once FTWRL has been run it should start another process that checks to make sure that process isn't blocked by anything (something that just started just as FTWRL was issued). If there is anything blocking at this point it should immediately kill the query so that FTWRL can finish successfully and the backup can complete. Logging what it killed would be nice.

        Smart Checklist




              • Assignee:
                lpjirasync lpjirasync (Inactive)
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: