Lockless binary log information
This is the XtraBackup part leveraging new server functionality in
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Alexey Kopytov
- Priority:
- Undefined
- Drafter:
- Alexey Kopytov
- Direction:
- Approved
- Assignee:
- Alexey Kopytov
- Definition:
- Approved
- Series goal:
- Accepted for 2.3
- Implementation:
-
Implemented
- Milestone target:
-
future-2.3-releases
- Started by
- Alexey Kopytov
- Completed by
- Alexey Kopytov
Related branches
Related bugs
Sprints
Whiteboard
https:/
When the
https:/
feature is available XtraBackup can trust binary log information stored
in the InnoDB system header and avoid executing LOCK BINLOG FOR
BACKUP (and thus, blocking commits for the duration of finalizing the
REDO log copy) under a number of circumstances:
- when the server is not a GTID-enabled Galera cluster node
- when the replication I/O thread information should not be stored as a
part of the backup (i.e. when the --slave-info option is not
specified)
If all of the above conditions hold, XtraBackup does not execute SHOW
MASTER STATUS as a part of the backup procedure, does not create the
xtrabackup_
retrieved and the file is created after preparing the backup, along with
creating xtrabackup_
exactly the same information as in xtrabackup_
redundant.
To make this new functionality configurable, there is now a new
XtraBackup option, --binlog-info, which can accept the following values:
- OFF. This means that XtraBackup will not attempt to retrieve the
binary log information at all, neither during the backup creation, nor
after preparing it. This can help when a user just wants to copy data
without any meta information like binary log or replication
coordinates. In this case, --binlog-info=OFF can be passed to
XtraBackup and LOCK BINLOG FOR BACKUP will not be executed, even if
the backup-safe binlog info feature is not provided by the server (but
the backup locks feature is still a requirement);
- ON. This matches the old behavior, i.e. the one before this XtraBackup
feature had been implemented. When specified, XtraBackup retrieves the
binary log information and uses LOCK BINLOG FOR BACKUP (if available)
to ensure its consistency
- LOCKLESS. This corresponds to the functionality explained above:
XtraBackup will not retrieve binary log information during the backup
process, will not execute LOCK BINLOG FOR BACKUP, and the
xtrabackup_
created after preparing the backup using the information stored in the
InnoDB system header. If the required server-side functionality is not
provided by the server, specifying this --binlog-info value will
result in an error. If one of the above mentioned conditions does not
hold, LOCK BINLOG FOR BACKUP will still be executed to ensure
consistency of other meta data.
- AUTO. This is the default value. When used, XtraBackup will
automatically switch to either ON or LOCKLESS, depending on the
server-side feature availability, i.e. whether the
have_