> 1. I need a read slave. With MariaDB Galera, I can slave a database of a local master, but Cockroach AFAIK can only do master master. Adding another node to a cluster that will just be read from seems like a lot of unneeded overhead, and can cause massive issues if there are sync issues.
I don't know whether CockroachDB can do this or not, but there's no reason raft followers can't serve stale reads. Given that, I don't understand this concern.
> 2. WAN sucks. Where I work, I've seen mysql slaves get hours out of sync due to packet loss. With a centralized system, I don't have to worry about reconciling data. If every site can accept data, then I have to assume that every site will remain in sync. If Site 1 gets out of sync and/or stops transmitting data, another site could make further changes to the record in question causing issues. Some places this is perfectly fine, but dealing with transactions of counting clicks, I do not want to be dropping data or running into conflicts.
The whole point of CockroachDB is that you never see inconsistencies (at least not without opting in to it). But if you are unable to talk to any of the other replicas then you would have to be dropping data. You don't really have a choice here, if you have a network partition, pick unavailability or consistency. This isn't something Galera can fix either.
1. In my research, raft followers would still be thinking for themselves. Each node could potentially become master, which would be fine in most cases, but I just want a dum stupid slave database to pull a read only copy. My concern is latency and load. I want to be able to predict hotspots. I don't want api-node-3 to become the leader for that site, I want db-1 and db-2 to be where everything happens.
> In my research, raft followers would still be thinking for themselves.
There is a lot more going on than vanilla raft. Cockroach's range lease feature (which is NOT the same as the raft leader election) automatically moves the lease to the node that minimizes latency. You can control this behavior via meta data and matching rules. I'd suggest skimming: https://www.cockroachlabs.com/docs/stable/demo-follow-the-wo...
Again, you're making a lot of assumptions that seem rooted in "cockroach == a raft cluster". There's a lot more going on than that.
> 1. I need a read slave. With MariaDB Galera, I can slave a database of a local master, but Cockroach AFAIK can only do master master. Adding another node to a cluster that will just be read from seems like a lot of unneeded overhead, and can cause massive issues if there are sync issues.
I don't know whether CockroachDB can do this or not, but there's no reason raft followers can't serve stale reads. Given that, I don't understand this concern.
> 2. WAN sucks. Where I work, I've seen mysql slaves get hours out of sync due to packet loss. With a centralized system, I don't have to worry about reconciling data. If every site can accept data, then I have to assume that every site will remain in sync. If Site 1 gets out of sync and/or stops transmitting data, another site could make further changes to the record in question causing issues. Some places this is perfectly fine, but dealing with transactions of counting clicks, I do not want to be dropping data or running into conflicts.
The whole point of CockroachDB is that you never see inconsistencies (at least not without opting in to it). But if you are unable to talk to any of the other replicas then you would have to be dropping data. You don't really have a choice here, if you have a network partition, pick unavailability or consistency. This isn't something Galera can fix either.