Forcing rotation of Aria log files

Forcing rotation of Aria log file

The new BACKUP SERVER commands needs an efficient way to copy Aria log files.
Copying all log files at BLOCK_COMMIT is not a good idea as this will causes
a notable stall blocking all commits.

Aria write log tables in blocks of 8K. It is append only, except for the last block that may get more data if there is room on the
page. This means that if one wants to copy it live in 'chunks', one should always copy up to the last aria_block_size block, but not the last page. The copy at end of backup should copy the rest of the file, including the last block.

The following options exists to solve this issue:

a)

• At backup start, stop aria log rotations and copy all old aria log tables
• At backup end (BLOCK_COMMIT) copy the last log table (which may be huge)

b)

• At backup start, stop aria log rotations and copy all old aria log tables.
  The current log table is copied up to the next to last block
• At backup end, copy new blocks in the current log table starting from
  where the first copy ended.

The problem with this approach is that when preparing the backup you
have join the original current log with the append log, which requires
some work on the 'using the backup' time. Marko would like the backup
to be 'ready to use' without any extra preparation work. Not sure if
this is doable, but that is his wish.

c)

• At backup start, stop aria log rotations, force Aria to move to a new
  log file. Copy all old aria log tables.
• At backup end, copy the current aria log table under BLOCK_COMMIT.

Potentially one could combine b) and c) so that just before BLOCK_COMMIT
one could copy the current log up to the next to last block, execute
BLOCK_COMMIT and copy the rest of the log (which should be very small).
The problem with this optimization is that we can only do this optimization
for one engine as the backup is expecting a stream and we cannot have
two streams continue with sending the last blocks.

The suggestion is to implement c) and leave the optimization for later.

The backup flow would then be something like:

• Start backup
• Copy transactional tables non blocking
• flush all logs (start new log files)
• Copy all old logs (not current)
• execute 'block commit'
• copy last log
• backup done

For this, we need a call to the Aria engine to force a log rotation.
Aria has already a call for this: translog_buffer_next()
However this call is only to be used from inside the log handler.
The task is to be able to call it through a handlerton call,
like handlerton->rotate_logs(). We already have a similar call
handlerton->flush_logs() which removes all not needed log files,
so having rotate_logs() would follow the same pattern.