Consider:
Make it a 4-node Galera Cluster. Have gcache set large enough to handle more than 30 minutes' worth of changes. Then let Galera take care of the rest.
Meanwhile, your clients should not connect just to galera4, but via a proxy to any node. (You may want to tell the proxy that "galera4" is preferred.)
But the real problem comes when you try to write to galera4 when it has lost connection to the other nodes. A core principle of Galera says that an isolated node (like that) shall not accept writes. Otherwise the data can become inconsistent.
Once you face that problem, you realize that "galera4" is not the solution. Instead, working on the network is the solution, and having the proxy robust enough to find a way to the 3-node datacenter is sufficient.
Or...
NDB Cluster is a different clustering offering from MySQL. It has a "eventually consistent" model for replication. You can have any number of disconnected Masters, write to any of them. The issue comes when you have conflicting writes (for example, two clients write with the same unique key). The inconsistency is "eventually" caught, but this could be long after the client finished talking to the Master that it happened to reach. At that point, some rule (such as "oldest timestamp wins") controls which record is kept and which is rejected.
NDB works well if you naturally are not going to write conflicting records.
