I'm seeing a lot of tutorials that claim I have to pick just one of the nodes in my master-master replicated PXC to act as master for an async slave using vanilla mysql replication, and if something goes wrong it's "easy to change the master to one of the other nodes." That's all well and good, but I don't want to be the one answering the pager at 2 a.m. to do a simple
CHANGE MASTER TO because one of my nodes went down. Ideally the point of an HA cluster is that all but one node can go down and all dependents are none the wiser.
It occurred to me that with GTID replication I might be able to get away with vanilla mysql multi-source replication, simply listing each node in the master-master PXC as a master to the async slave. They all replicate the same gtid's, which would be idempotent on duplicate updates to the slave, right? Would that work?
Or: is there a better way?
Based on Rick James answer I feel I must clarify. The PXC cluster is in a single data center and is a three node HA setup all well and good on its own. The Async Slave would be an additional 4th node, out of data center and at the end of a high latency VPN/WAN link, not running PXC/Galera at all, but instead just a regular Percona Server instance replicating over vanilla GTID/Binlog Master/Slave replication against the PXC cluster. The goal is that it can treat each of the 3 nodes in the PXC cluster as a master. The problem is that the tutorials I read say I have to choose only one to be the master, and thus the single point of failure - not for the cluster, but for the role of "master status" for this 4th node async slave until somebody goes and changes which master it is tracking by hand. This is why I'm hoping to do multi-source vanilla replication treating each PXC node as its own master to the slave; as long as one stays up, the remote slave stays in sync.
I can not merely switch the slave to run PXC and make it a 4th distributed node in the cluster because it will not be replicating the entire database but only certain tables; because it is a lower power than the existing cluster nodes; and because I do not want to slow down the cluster (which is used in high-performance production and needs ACID compliance) with the slave (which is allowed to get out of sync a little bit).