You can perform deployment using unidirectional (master-follower) or bidirectional (multi-master) asynchronous replication between universes (also known as data centers).
For information on two data-center (2DC) deployment architecture and supported replication scenarios, see Two data center (2DC) deployments.
Setting Up Universes
You can create producer and consumer universes as follows:
- Create the yugabyte-producer universe by following the procedure from Manual deployment.
- Create tables for the APIs being used by the producer.
- Create the yugabyte-consumer universe by following the procedure from Manual deployment.
- Create tables for the APIs being used by the consumer. These should be the same tables as you created for the producer universe.
- Proceed to setting up unidirectional or bidirectional replication.
Setting Up Unidirectional Replication
After you created the required tables, you can set up asynchronous replication as follows:
Look up the producer universe UUID and the table IDs for the two tables and the index table:
To find a universe's UUID, check
--cluster_uuid. If it is not available in this location, check the same field in the cluster configuration.
To find a table ID, execute the following command as an admin:
yb-admin list_tables [include_table_id]
Run the following
setup_universe_replicationcommand from the YugabyteDB home directory in the producer universe:
./bin/yb-admin \ -master_addresses <consumer_universe_master_addresses> \ setup_universe_replication <producer_universe_uuid> \ <producer_universe_master_addresses> \ <table_id>,[<table_id>..]
./bin/yb-admin \ -master_addresses 127.0.0.11:7100,127.0.0.12:7100,127.0.0.13:7100 \ setup_universe_replication e260b8b6-e89f-4505-bb8e-b31f74aa29f3 \ 127.0.0.1:7100,127.0.0.2:7100,127.0.0.3:7100 \ 000030a5000030008000000000004000,000030a5000030008000000000004005,dfef757c415c4b2cacc9315b8acb539a
The preceding command contains three table IDs: the first two are YSQL for the base table and index, and the third is the YCQL table.
Also, be sure to specify all master addresses for producer and consumer universes in the command.
Setting Up Bidirectional Replication
To set up bidirectional replication, repeat the procedure descried in Setting Up Unidirectional Replication applying the steps to the yugabyte-consumer universe. You need to set up each yugabyte-producer to consume data from yugabyte-consumer.
When completed, proceed to Loading Data.
Loading Data into the Producer Universe
Once you have set up replication, load data into the producer universe as follows:
Download the YugabyteDB workload generator JAR file
Start loading data into yugabyte-producer by following examples for YSQL or YCQL:
java -jar yb-sample-apps.jar --workload SqlSecondaryIndex --nodes 127.0.0.1:5433
java -jar yb-sample-apps.jar --workload CassandraBatchKeyValue --nodes 127.0.0.1:9042
Note that the IP address needs to correspond to the IP of any T-Servers in the cluster.
For bidirectional replication, repeat the preceding step in the yugabyte-consumer universe.
When completed, proceed to Verifying Replication.
You can verify replication by stopping the workload and then using the
COUNT(*) function on the yugabyte-consumer to yugabyte-producer match.
For unidirectional replication, connect to the yugabyte-consumer universe using the YSQL shell (
ysqlsh) or the YCQL shell (
ycqlsh), and confirm that you can see the expected records.
For bidirectional replication, repeat the procedure described in Unidirectional Replication, but reverse the source and destination information, as follows:
yb-admin setup_universe_replicationon the yugabyte-consumer universe, pointing to yugabyte-producer.
- Use the workload generator to start loading data into the yugabyte-consumer universe.
- Verify Replication from yugabyte-consumer to yugabyte-producer.
To avoid primary key conflict errors, keep the key ranges for the two universes separate. This is done automatically by the applications included in the
Replication lag is computed at the tablet level as follows:
replication lag = hybrid_clock_time - last_read_hybrid_time
hybrid_clock_time is the hybrid clock timestamp on the producer's tablet-server, and last_read_hybrid_time is the hybrid clock timestamp of the latest record pulled from the producer.
The following example generates a replication lag summary for all tables on a cluster. You can also request an individual table.
./determine_repl_latency.sh -m 10.150.255.114,10.150.255.115,10.150.255.113
To obtain a summary of all command options, execute
determine_repl_latency.sh -h .