Comment 17 for bug 1401133

Hello,
We had the same error inside our 9 nodes cluster :
 - percona-xtrabackup 2.2.9
 - percona-xtradb-cluster-server-5.6 5.6.22-25.8-978
------------------------------------------
root@db # innobackupex --help | grep lock
        This option controls if backup locks should be used instead of FLUSH
        when backup locks are not supported by the server. This option is
        enabled by default, disable with --no-backup-locks.
    --debug-sleep-before-unlock=SECONDS
        effect when backup locks are used to create the backup.
        queries that block it. Default is 0 seconds, which means
        unblock the global lock. Default is "all".
    --lock-wait-timeout=SECONDS
        for queries that would block FTWRL before running it. If there are
    --lock-wait-threshold=SECONDS
        --lock-wait-timeout. FTWRL is not started until such long-running
        queries exist. This option has no effect if --lock-wait-timeout is
    --lock-wait-query-type=all|update
        before innobackupex will issue the global lock. Default is all.
    --no-lock
        Use this option to disable table lock with "FLUSH TABLES WITH READ
        inconsistent backup. If you are considering to use --no-lock because
        your backups are failing to acquire the lock, this could be because
        of incoming replication events preventing the lock from succeeding.
-------------------
Adding :
[sst]
inno-backup-opts='--no-backup-locks'
does not resolve the problem.

When you call the binary 'xtrabackupex' you may use '--no-backup-locks' or '--no-locks' directly as parameters to resolve this pb.