Lockless binary log information

Registered by Alexey Kopytov on 2015-07-28

This is the XtraBackup part leveraging new server functionality in
https://blueprints.launchpad.net/percona-server/+spec/backup-safe-binlog-info

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:
milestone icon future-2.3-releases
Started by
Alexey Kopytov on 2015-07-28
Completed by
Alexey Kopytov on 2015-07-28

Related branches

Sprints

Whiteboard

https://github.com/percona/percona-xtrabackup/pull/90

When the
https://blueprints.launchpad.net/percona-server/+spec/backup-safe-binlog-info
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_binlog_info file on backup. Instead, that information is
retrieved and the file is created after preparing the backup, along with
creating xtrabackup_binlog_pos_innodb, which in this case contains
exactly the same information as in xtrabackup_binlog_info and is thus
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_binlog_info file will not be created. The file will be
  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_backup_safe_binlog_info server variable is available.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.