Thanks for the prompt response, Jay. 🙂

That’s a bug and it should be reported as such here: https://bugs.launchpad.net/percona-xtradb-cluster/+filebug
It’s likely something special with your config. I don’t like having a special config per host just because it complicates things operationally.

>> Secondly, since XtraDB Cluster already uses its own internal transaction UUIDs, it seems to me that using MySQL 5.6 GTIDs within XtraDB Cluster would be redundant. What is your viewpoint on this?

If you are using async replication with PXC, then GTIDs for that may be of some value for you: https://www.percona.com/blog/2014/02/14/changing-async-slave-pxc-cluster-new-master-using-5-6-gtid/

>> And third, do you see any problem with using innodb_buffer_pool_dump_at_shutdown and innodb_buffer_pool_load_at_startup with XtraDB Cluster? Do you have an opinion on whether it should or should not be used?

No, it should generally be fine.

First, I have occasionally run into problems in which a joining node will try to connect to *itself*, and fail, if its address is the first in wsrep_cluster_address. Since this variable is fully maintained in memory by the cluster once the node joins, I have taken to omitting each node’s own address from wsrep_cluster_address. Do you see any problem with this practice, or any reason why it should not be done, other than convenience in setting up the config file?

Secondly, since XtraDB Cluster already uses its own internal transaction UUIDs, it seems to me that using MySQL 5.6 GTIDs within XtraDB Cluster would be redundant. What is your viewpoint on this?

And third, do you see any problem with using innodb_buffer_pool_dump_at_shutdown and innodb_buffer_pool_load_at_startup with XtraDB Cluster? Do you have an opinion on whether it should or should not be used?