Comment 6 for bug 1595394

I don't fully understand your response but the issues I rise are real and must be addressed before accepting this change into the product. We are willing to do some of the work on our side to make this production ready but we will not introduce a half-implemented feature set into the product.

On point 2, I think you missed my meaning. The recovery log copy should begin at the start of the backup, after the checkpoint lock has been placed and the file monitored for changes all throughout the backup until the FTWRL or LTFB. This is how the InnoDB backup works and is necessary for InnoDB due to the way the redo log is fixed sized rolling log. PerconaFT log is not a fixed sized rolling log, they will grow until it runs out of disk. By copying and monitoring in parallel, it will shorten the time needed during the FTWRL/LTFB that finalizes the last position/entry within the file.

On point 4, you are incorrect, when a session ends/terminates, the tokudb_checkpoint_lock will not be automatically released. It is a session variable that 'acts' like a global, meaning that one session can "set session tokudb_checkpoint_lock=true;" and it will globally disable checkpointing within PerconaFT, then another session can do a "set session tokudb_checkpoint_lock=false;" and globally re-enable checkpointing within PerconaFT. When a session closes, the session variables are simply thrown away, they are not 'unset'. So again, this is a bad way to handle disabling a critical function such as checkpointing and needs a better mechanism to ensure that in the event of an unexpected session termination, checkpointing gets re-enabled within the server.

On point 5, PerconaFT only truncates a PerconaFT data file on open, so unless the file is closed (the owing table happens to get evicted from the MySQL open table cache) or the server shutdown, this space is still allocated to the file during the backup and normal operation thereafter. This means that in theory, the worst possible case, you would need to have reserve file system capacity of 2x your data size plus whatever excess recovery log size. Due to the way the file map works, truncation may not even do anything if there is live data at the tail of the file (which is a distinct possibility because of the reason it was allocated in the first place, evicted dirty nodes not checkpointed), leaving all of the empty space within the file still allocated.

A backup operation is _not_ supposed to cause or alter server(mysqld) behavior or resource needs, which this approach does via file system space demands. Just because it works for you does not mean that it is an acceptable trade-off or solution for everyone and needs to be properly vetted before accepting the idea. Any potential problematic areas need to be identified and fully tested and documented so any user considering the product understands the tradeoffs.

As far as MyRocks, you are on your own there for the time being. It is not used in production yet by even the people that are developing it and still has many issues. It is not yet supported by Percona in any way.