How YugabyteDB handles conflict between regions in multi-region replication

Question

I was looking into how yugabyte handles conflict between regions and found this https://www.yugabyte.com/tech/database-geo-distribution/ However, I cannot find any more information regarding asynchronous replication (Last Writer Wins) in the documentation. Then I found another information in the documentation https://docs.yugabyte.com/preview/develop/learn/sql-nosql/#geo-distributed, which states that yugabyte can perform strongly consistent writes (in 218ms) that involves 5 nodes. My question:

1. Geo-distributed is just having read replicas, or read/write replicas? (Or am I misunderstanding something)
2. In the case where a read/write replica is needed in multiple regions, is it mandatory to use asynchronous replication (and how is this setup)?
3. How is strongly consistent writes being implemented in this particular case? Does it involve sharding?

Answer 1

For synchronous replication:

1. Geo-distributed: with geo-distribution, the geo-distribution part is applied by placing the raft group members in specific geo-locations. Any object uses one or more YugabyteDB tablets, for which the tablet is another name for a raft group. So that means that the members of the raft group, called replicas, are distributed. On the database level, there is one object.
2. Replicas in multiple regions: in the case I described above, the replicas are kept up to date by raft consensus. Not replication. Updates by raft conensus are “somewhat” alike synchronous replication, however only the majority need to be up to date with the leader (=consensus), the others are also getting the updates, but have not reported being up to date yet.
3. This automatically means in the situation I described above, that writes are strongly consistent by using raft consensus. The raft consensus mechanism is not replication in the traditional sense of replication of replicating to an identical database at another place, as I indicated in the above description.

However, I cannot find any more information regarding asynchronous replication (Last Writer Wins) in the documentation.

This is xCluster which is asynchronous replication between clusters. It is not mandatory for multi-region. You have multiple choices. Example:

• 3 regions, one cluster (with synchronous replication) stretched across regions. This adds latency, so one practice is to set preferred leaders in one region, to avoid cross-region transactions. The writes will wait for the quorum of other regions, so better to have one not too far. All is consistent. You need 3 regions (for a replication factor 3 cluster) to always have a quorum but you are fully resilient in case of region disaster
• 2 regions, one cluster in each regions, with asynchronous replication (xCluster) between them. This is better for latency (the sync replication is between AZ in single region) but in case of region disaster you may have small data loss. You can do 2-way replication between cluster, but last writer wins. Typically you connect only to one region and switch to the other in case of disaster recovery or maintenance on the first region. You can connect to both if you are sure to