{"push_id":739983984,"size":1,"distinct_size":1,"ref":"refs/heads/lockless_binlog_info","head":"4001b573f79e96c2a026f8d035042a166ab162bd","before":"cb22d1e9098c1db088961e69eeea7f6aad976dab","commits":[{"sha":"4001b573f79e96c2a026f8d035042a166ab162bd","author":{"email":"cdecb3981ce42fd999099ecef00dccec9b3439ec@gmail.com","name":"Alexey Kopytov"},"message":"Implementation of\nhttps://blueprints.launchpad.net/percona-xtrabackup/+spec/lockless-binlog-info\n\nWhen the\nhttps://blueprints.launchpad.net/percona-server/+spec/backup-safe-binlog-info\nfeature is available XtraBackup can trust binary log information stored\nin the InnoDB system header and avoid executing LOCK BINLOG FOR\nBACKUP (and thus, blocking commits for the duration of finalizing the\nREDO log copy) under a number of circumstances:\n\n- when the server is not a GTID-enabled Galera cluster node\n- when the replication I/O thread information should not be stored as a\n  part of the backup (i.e. when the --slave-info option is not\n  specified)\n\nIf all of the above conditions hold, XtraBackup does not execute SHOW\nMASTER STATUS as a part of the backup procedure, does not create the\nxtrabackup_binlog_info file on backup. Instead, that information is\nretrieved and the file is created after preparing the backup, along with\ncreating xtrabackup_binlog_pos_innodb, which in this case contains\nexactly the same information as in xtrabackup_binlog_info and is thus\nredundant.\n\nTo make this new functionality configurable, there is now a new\nXtraBackup option, --binlog-info, which can accept the following values:\n\n- OFF. This means that XtraBackup will not attempt to retrieve the\n  binary log information at all, neither during the backup creation, nor\n  after preparing it. This can help when a user just wants to copy data\n  without any meta information like binary log or replication\n  coordinates. In this case, --binlog-info=OFF can be passed to\n  XtraBackup and LOCK BINLOG FOR BACKUP will not be executed, even if\n  the backup-safe binlog info feature is not provided by the server (but\n  the backup locks feature is still a requirement);\n\n- ON. This matches the old behavior, i.e. the one before this XtraBackup\n  feature had been implemented. When specified, XtraBackup retrieves the\n  binary log information and uses LOCK BINLOG FOR BACKUP (if available)\n  to ensure its consistency\n\n- LOCKLESS. This corresponds to the functionality explained above:\n  XtraBackup will not retrieve binary log information during the backup\n  process, will not execute LOCK BINLOG FOR BACKUP, and the\n  xtrabackup_binlog_info file will not be created. The file will be\n  created after preparing the backup using the information stored in the\n  InnoDB system header. If the required server-side functionality is not\n  provided by the server, specifying this --binlog-info value will\n  result in an error. If one of the above mentioned conditions does not\n  hold, LOCK BINLOG FOR BACKUP will still be executed to ensure\n  consistency of other meta data.\n\n- AUTO. This is the default value. When used, XtraBackup will\n  automatically switch to either ON or LOCKLESS, depending on the\n  server-side feature availability, i.e. whether the\n  have_backup_safe_binlog_info server variable is available.","distinct":true,"url":"https://api.github.com/repos/akopytov/percona-xtrabackup/commits/4001b573f79e96c2a026f8d035042a166ab162bd"}]}