@aredman Hey there, and welcome. If you came to us as an official client with that design desire, I’d ask you why, and would want to hear all of your logic behind the choice. Many, many times our clients come to us with big massive complex desires which, in reality and in practice, never pan out and end up as an over-engineered solution to an extremely standard problem. With only your paragraph, 6 DCs attempting to be all active and in-sync feels over-engineered, and/or attempting to solve a problem that doesn’t exist.
In my head, this is where I compare you to other clients of ours. I’ve been directly involved with several high-end retailers setting up their MySQL environments for high-traffic black friday and nobody has that complex of a WAN DB setup.
Is PXC wrong? Not necessarily. You can certainly implement a 6 node PXC with one node in each DC, local applications connecting to local DB, and PXC maintaining quorum. But your commit speed on any node cannot be faster than the slowest link between any two nodes, since PXC used synchronous replication.
My example above is very typical: Primary DC has a full, local cluster and apps talk directly to all nodes (using ProxySQL or other middleware to load-balance read-only queries across all nodes while sending write traffic to a single node). In other DCs, using native mysql async replication, stand up another PXC and replicate traffic. App servers in this DC are also on standby. If your latency was acceptable, you could have apps in DR DCs talk directly to primary PXC DC (this is common setup too). Should you need to failover, the PXC in DR might be just a few transactions behind in lag, but otherwise in sync. Switch apps to connect to this PXC.