Binlog Servers for Simplifying Point in Time Recovery

A common way to implement point in time recovery capability is:

1. to regularly do a full backup of a database,
2. and to save the binary logs of that database (or from its master if doing backups on a slave).

When point in time recovery is required you need to:

1. restore a backup,
2. and apply the binary logs up to the point of recovery.

(Step # 2 and # b above are the ones that will be simplified by using Binlog Servers.)

Do not run those commands with MariaDB GTIDs - part # 2

Update 2016-01-30: restarting the IO_THREAD might be considered useful in some situations (avoiding MDEV-9138).  Look for "in contrast, if the IO thread was also stopped first" in MDEV-6589 for more information.

In a previous post, I listed some sequences of commands that you should not run on a MariaDB slave that is lagging and which is using the GTID protocol.  Those are the following (do not run them, it's a trap):

• "STOP SLAVE; START SLAVE UNTIL ...;",
• or "STOP SLAVE; START SLAVE;" (to remove an UNTIL condition as an example),
• or "STOP SLAVE; SET GLOBAL slave_parallel_threads=...; START SLAVE;",
• and maybe others.

Do not run those commands with MariaDB GTIDs - part # 1

In the spirit of sharing war stories and avoiding others to do the same mistakes as I did, here are some sequences of commands that you should avoid to run on a MariaDB slave that is lagging and which is using the GTID protocol.  Remember, do not run those because...