innobackupex should not allow --no-lock --galera-info

Confirmed.

Now, this fails because,

from innobackupex:
===========
    if (!$option_no_lock) {
        # make a prep copy before locking tables, if using rsync
        backup_files(1);

        # flush tables with read lock
        mysql_lockall();
    }
=======

and write_galera_info is called from mysql_lockall

write_galera_info mainly does:

    # get binlog position
    mysql_send "SHOW STATUS LIKE 'wsrep_local_state_uuid';";
    mysql_send "SHOW STATUS LIKE 'wsrep_last_committed';";

Now, it needs to checked if above does require FTWRL or not.

we need to have FTWRL to get consistent Galera position.
--no-lock can not be used for SST.

Later when Galera supports lockless snapshot we can handle it differently.

I am setting bug as "Invalid"

During a SST from the donor node, writes are disabled, so it is interesting to see if wsrep_local_state_uuid and wsrep_last_committed change during SST or not (my guess is they do not).

Also, adding Xtrabackup project here since changes, if any, are required in that.

@Vadim, Thanks, so locking is required then.

However, if both --no-lock and --galera-info are given, innobackupex code should fail or atleast print a warning to the error log rather than silently fail with broken pipe as in case of PXC.

Currently, there is nothing in donor innobackup.backup.log about this and joiner error log only has:

120927 22:20:25 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup 'joiner' '10.0.2.154' '' '/var/lib/mysql/' '/etc/my.cnf' '3629' 2>sst.err: 32 (Broken pipe)
120927 22:20:25 [ERROR] WSREP: Failed to parse uuid:seqno pair: 'xtrabackup process ended without creating '/var/lib/mysql//xtrabackup_galera_info''

Actually, Galera, atleast now, supports wsrep replication position in InnoDB headers, much like how the replication position is stored and recovered during prepare phase of Xtrabackup.

According to discussion I had, it stored as follows:

""
Wsrep GTID is found from InnoDB sys_header + TRX_SYS_WSREP_XID_INFO, see:
* storage/innobase/include/trx0sys.h for TRX_SYS_WSREP_XID_INFO and other definitions
* storage/innobase/trx/trx0sys.c:trx_sys_read_wsrep_checkpoint() for reading XID from sys_header
* sql/wsrep_mysqld.h and sql/wsrep_utils.cc how to read GTID from XID (wsrep_xid_{uuid|seqno})
* XID is defined in sql/handler.h and storage/innobase/include/trx0xa.h
""

May be a different bug can be opened for this if required.

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-83