Mysql replication between 3 + 1 nodes Suppose I have the following configuration for mysql 5.6 replication.
Nodes
A
B
C
D
Nodes A,B,C have wsrep_cluster_address set to respective ip's of nodes A,B and C. Then node D has wsrep_cluster_address set to respective ip's of nodes A,B,C and D.
Then when data is written to nodes A,B,C it is replicated to A,B,C,D, but when data write happens on D - it won't get replicated to A,B,C - is that right ?
Also, what happens when data is written on D and same record is changed on either A,B or C - does it get overwritten based on time of the actual change ?
Really the goal of D is just to have a constantly replicated copy in another zone in case a disaster happens.
Have a cluster with nodes A,B,C, but not D.
Have D be a Slave to one of the nodes.  Do not configure it as a wsrep node.  Do not write to it.
More
A cluster with 3 or more nodes provides HA and failover if any one node goes down.
If those 3 nodes are in the same datacenter, then they are vulnerable to a disaster that takes down the DC.  (That can happen.)
If those 3 nodes are in 3 geographical locations, the cluster can survive the lost of any one of them.  Hence, it is better than 3 in a single DC.
When something happens with a cluster, all the alive nodes vote to see what the situation is.  If more than 50% can talk to each other, they will declare that they are the (degraded) cluster, and that the other node(s) will need repairing when (if) they reconnect.
If you have 3 nodes in one DC and a 4th in another DC, the cluster will not survive an outage of either DC.
If those two DCs lose connectivity, but everything other than the network stays up, the DC with 3 nodes won't be able to see the 4th; they will kick it out of the cluster.  The lone #4 will see that it can't get 50%+, so it stops accepting writes (at least).
Back to your question...
A 3-node cluster in one DC; a 4th node in another DC.  If the 3-node DC goes dark, you could manually build a new cluster around the 4th.  But that is far from automated.  You could, however, say that a DC going down (and not coming back up 'soon') is so rare that you are willing to build this topology.  And, if the DC never comes back up (tornado, flood, earthquake, tsunami), you would have a copy of the data in #4.  Better than nothing.
So, if you go with 3+1, I recommend that the 3 is a fully functioning Galera cluster.  (Or it could even be 2 live + 1 garbd.)  Then #4 would be an ordinary replica that is asynchronously replicating from one of the 3 nodes.
With that config, Galera does not know or care about #4, and is not burdened by long-distance syncing of gcache.
It's a tradeoff between vulnerability and speed.  You can't solve both.  Hopefully, I have given you enough understanding of what can be done so that you can decide what &quot;keeps you up at night&quot; the least.