The test uses a debug feature SHOW PROCEDURE|FUNCTION CODE.

  If any given variable the xtrabackup-v2 sst script looks for is specified
  multiple times in cnf file then it tend to pick both of them causing
  some of the follow-up command to fail.

  Avoid this programatic mistake by honoring only the last variable assigned
  setting as done by mysqld too.

  Check https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1362830

Semantics:
---------

* Generally end-user will create a separate user with needed
privileges for
    performing DONOR action.
* This user credentials are specified using wsrep_sst_auth.

* Along with this user there could be other user(s) created on the
server
    that sysadmin may use for normal or other operations
* Credentials for these user(s) can be specified in same
cluster/server
    cnf file as part of [client] section

When cluster act as DONOR and if wsrep_sst_auth is provided then it
should
strictly use it for performing SST based action.

What if end-user has same credentials for performing both SST action
and
normal admin work ?
* Then end-user can simply specify these credentials as part of
[client]
    section in cnf file and skip providing wsrep_sst_auth.

Issue:
-----

MySQL client user/password parsing preference order is as follows:
* command line (through --user/--password)
* cnf file
* MYSQL_PWD enviornment variable.

Recent change tried passing sst user password through MYSQL_PWD
(and user though --user command line param as before).

On the system where-in admin had another user for performing non-SST
actions,
credentials for such user were present in cnf file under [client]
section.

Due to mysql client preference order, SST user name was used (as it
was
passed through command line) but password of other user (meant for
non-SST)
action was being used as it was passed through cnf file.

Password passed through MYSQL_PWD was completely ignored causing
user-name/password mismatch.

Solution:
---------

* If user has specified credentials for SST then pass them through
command
    line so that they are used in priority.

(There could be security concern on passing things through command
line but
   when I tried passing user-name and password through command line to
mysql
   client and then did ps I saw this
   ./bin/mysql --user=sstuser --password=x xxxxxxxx -S /tmp/n1.sock
so seems like password is not shown)

- test for FLUSH TABLES hang in slave node

- avoiding the race condition, by not grabbing thd->LOCK_wsrep_thd for
  accessing thd->wsrep_exec_mode. The caller is same thread and exec mode
  can only be changed by self.

- added mtr test case for this issue
- not a perfect one, depends on some sleeps instead of checking
  if sync points are met

- added dbug sync points for further mtr test for this issue

- Add calls to wsrep_sync_wait for
  SHOW CREATE DB/PROCEDURE/FUNCTION/TRIGGER/EVENT
  and SHOW PROCEDURE/FUNCTION CODE

Galera MTR Tests: adjust the galera.galera_defaults test for the new MTR default value for repl.causal_read_timeout

Fix remaining issues with wsrep_sync_wait and query cache.

- Fixes misplaced call to invalidate query cache in
  Rows_log_event::do_apply_event().
  Query cache was invalidated too early, and allowed old
  entries to be inserted to the cache.

- Reset thd->wsrep_sync_wait_gtid on query cache hit.
  THD->cleanup_after_query is not called in such cases,
  and thd->wsrep_sync_wait_gtid remained initialized.

Restore tests for FLUSH commands supported by MariaDB.

* Total order isolation was started twice for FLUSH TABLES, from
  reload_acl_and_cache() and from mysql_execute_command(). Removed
  the reload_acl_and_cache() part.
* Removed PXC specific stuff from MTR tests

- Eliminates code duplication in query cache patch
- Reduces the number of iterations in mysql-wsrep#201.test
  to shorten the execution time
- Adds a new test case that exercises more scenarios

- Restore FLUSH commands supported by MariaDB (removed in
the previous commit)
- Adjust test case

Added following:

        FLUSH CLIENT_STATISTICS
        FLUSH INDEX_STATISTICS
        FLUSH TABLE_STATISTICS
        FLUSH THREAD_STATISTICS
        FLUSH USER_STATISTICS

pertaining to USER STATISTICS
https://www.percona.com/doc/percona-server/5.6/diagnostics/user_stats.html

        FLUSH CHANGED_PAGE_BITMAPS

pertaining to changed page tracking.
https://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html

Also, added tests for them.

(cherry picked from commit 7efe49010c7f217663f364657090812b4723f426)

Conflicts:
	mysql-test/suite/galera/r/galera_flush.result
	mysql-test/suite/galera/r/galera_flush_gtid.result
	mysql-test/suite/galera/t/galera_flush.test
	sql/sql_parse.cc

The admin commands in question are:
    > OPTIMIZE
    > REPAIR
    > ANALYZE

For LOCAL or NO_WRITE_TO_BINLOG invocations of these commands, ie

    OPTIMIZE LOCAL TABLE <t1>

they are not binlogged as expected.

Also, in addition, they are not executed under TOI.

Hence, they are not propagated to other nodes.

The effect is same as that of wsrep_on=0.

Also added tests for this.

A WSREP_DEBUG for wsrep_register_hton has also been added.

The galera_flush_local test has also been updated for verifying that effects
of  NO_WRITE_TO_BINLOG / LOCAL are equivalent to wsrep_on=0 from wsrep
perspective.

(cherry picked from commit 5065122f94a8002d4da231528a46f8d9ddbffdc2)

Conflicts:
	sql/sql_admin.cc
	sql/sql_reload.cc
	sql/wsrep_hton.cc

Galera MTR Tests: stability fix for galera_gcs_fragment.test (TCP port was output to the .result file)

- Fixes query cache so that it is aware of wsrep_sync_wait.
  Query cache would return (possibly stale) results to the
  client, regardless of the value of wsrep_sync_wait.
- Includes the test case that reproduced the issue.

Merge fix to XtraDB engine.

- Adds runtime check wsrep_on(), to not interfere with default
  innodb behavior.

- Avoid calling wsrep->stats_free() directly, instead, use wsrep_free_status().

- Moves cleanup of status vars to function export_wsrep_status_to_mysql().

Merge fix to XtraDB engine.

Fixes a deadlock between applier and its victim transaction.
The deadlock would manifest when a BF victim was waiting for some lock
and was signaled to rollback, and the same time its wait
timeout expired. In such cases the victim would return from
lock_wait_suspend_thread() with error DB_LOCK_WAIT_TIMEOUT, as opposed to
DB_DEADLOCK. As a result only the last statement of the victim would rollback,
and eventually it would deadlock with the applier.