Being a distributed SQL database, YugabyteDB automatically splits the data in a table and distributes it across nodes. This is known as data sharding. Data sharding helps in scalability and geo-distribution by horizontally partitioning data.
Using the Raft distributed consensus protocol, YugabyteDB automatically replicates data synchronously in order to survive failures while maintaining data consistency and avoiding operator intervention.
YugabyteDB replicates data across nodes (or fault domains) in order to tolerate faults. Replication of data in DocDB (YugabyteDB’s storage layer) is achieved at the level of tablets, using tablet peers, with each table sharded into a set of tablets.
As soon as a tablet initiates, it elects one of the tablet peers as the tablet leader using the Raft protocol. The tablet leader becomes responsible for processing user-facing write requests by translating the user-issued writes into the document storage layer of DocDB.
If application reads and writes are known to be originating primarily from a single region, you can designate a preferred region, which pins the tablet leaders to that single region. As a result, the preferred region handles all read and write requests from clients. Non-preferred regions are used only for hosting tablet follower replicas.
You can specify a region in YB Anywhere on the Edit Universe page. In the example below, the AWS us-west-2a in the preferred region.
In YugabyteDB it’s important to understand that just like user tables, system tables are also split into shards and replicated.
By default system tables do not honor the selected preferred region. To enable that feature, set the Master Server gFlag transaction_tables_use_preferred_zones to true.
By default it is set to false…
[root@localhost ~]# curl -s http://master-IP:7000/varz?raw | grep transaction_tables_use_preferred_zones
--transaction_tables_use_preferred_zones=false
If using YB Anywhere, use the “Edit Flags” tool to modify the transaction_tables_use_preferred_zones gFlag.
Have Fun!
