Make backup locks compatible with cluster

Registered by Alexey Kopytov on 2014-06-08

UPDATE (KAlexey, 2014-06-28): it's been decided that a better way to retrieve Galera GTID would be to read TRX_SYS_WSREP_* fields from InnoDB data files. This way we don't need any additional locks to protect wsrep_last_commited during the backup stage, so this blueprint is unnecessary.

A Galera cluster node requires more data structures to be protected by
backup locks than a regular MySQL server. When backing a Galera cluster
node, backup tools also query the following status variables as a part
of the backup process:

wsrep_local_state_uuid
and
wsrep_last_committed

The former is assigned a value on server startup and never changes
during runtime. The latter is updated on each commit as the name
implies.

When backup locks are not available, those variables are queried on a
read-only server, i.e. under FTWRL, which also blocks commits, so
wsrep_last_committed is guaranteed to have a consistent value.

When backup locks are available, those variables are queried under LOCK
TABLES FOR BACKUP + LOCK BINLOG FOR BACKUP. None of those statements
currently prevents wsrep_last_committed from being updated.

The goal of this blueprint is to change the semantics of LOCK BINLOG FOR
BACKUP for Percona XtraDB Cluster: instead of blocking updates to binary
log coordinates (when binary log is enabled), LOCK BINLOG FOR BACKUP
should block all commits regardless of the binary log state, because
every commit will update wsrep_last_committed.

Blueprint information

Status:
Not started
Approver:
Alexey Kopytov
Priority:
Not
Drafter:
Alexey Kopytov
Direction:
Approved
Assignee:
Alexey Kopytov
Definition:
Approved
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(how does this boody thing work? - I mean the "whiteboard"?)
Anyway. quering wsrep_last_committed is a somewhat perverted way to learn the last committed seqno inside mysqld as it works only with FTWRL and its value is updated well after the commit actually happened: i.e. at first mysqld commits transaction and only after that the value is updated.

At the same time, mysqld is well aware of the seqno during commit (it is passed via commit callback) and moreover, it stores it in innodb tablespace (that goes only for innodb commits of course). Not sure how exactly this helps with backup locks, but the committing thread can synchronously udate any structure inside mysqld with the current seqno, which, if needed, can be protected by backup lock.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.