Configuring Replication

This chapter explains how to configure your GridGain clusters for data replication by using the CLI tool.

Preparing for Replication

By default, data center replication assumes that the clusters share the schema and the replica cluster database is empty. If there is data in replica cluster’s tables already, it will not be overwritten, instead new data will be added to the table.

Connecting to Source Server

To connect to a source cluster, use the dcr create command:

dcr create --name replication_name --source-cluster-address=127.0.0.1:10800

This command creates a connection, but does not start replication on its own. The name of the replication will be used later to address it in the commands.

Starting Replication

To start replication, use the dcr start command:

dcr start replication_name --schema=PUBLIC --all

The cluster will start the data replication process from the cluster running on the 127.0.0.1 address, and will copy all tables from it.

When the replication is first started, the source cluster will perform a special operation called full state transfer, fully replicating the data from the source cluster to the replica cluster.

Afterwards, updates to the source cluster will be copied to the replica cluster.

Limiting Replicating Nodes

By default, all nodes in the cluster are involved in the replication process. Sending data to the replica cluster can increase load on nodes, and slow down your application. To avoid this, you can narrow down the list of nodes that send data by listing the consistent IDs of all nodes involved in replication in the replication-nodes.

dcr start replication_name --schema=PUBLIC --replication-nodes=defaultNode,otherNode --all

Limiting Replication Scope

If necessary, you can replicate data only from some tables in the cluster. To do this, use the tables option instead of all.

dcr start replication_name --schema=PUBLIC --tables=myTable1,myTable2

If set, only the specified table will be copied to the replica cluster.

Replication on Secured Clusters

If your cluster has security enabled, you need to provide user credentials to the dcr create command to establish secure connection and authorization. The user needs to have a role with permissions that allow them to read and write to the tables that are being replicated.

dcr create replication_auth  --source-cluster-address=127.0.0.1:10800 --username admin --password myPass

dcr start replication_auth --schema=PUBLIC --all

If your cluster is further secured by using SSL, you need to provide keystore and truststore that will be used to connect to it in the dcr create command:

dcr create replication_ssl --source-cluster-address=127.0.0.1:10800 --keyStorePath=path-to-keystore --keyStorePassword=myPass --trustStorePath=path-to-truststore --truestStorePassword=myPass

dcr start replication_ssl --schema=PUBLIC --all

One-Time Replication

In some scenarios, it is not necessary to copy data dynamically. Instead, you can flush data once. When running the flush command, you specify the replication timestamp. All data up to that point will be replicated, and then the replication will stop automatically.

dcr flush replication_name --replication-timestamp=1719221491

Checking Replication Status

You can list the currently existing replications by using the list command:

dcr list

This command lists all existing replications and their statuses. You can get more in-depth information on each replication by using the status command:

dcr status replication_name

Stopping Replication

To stop replication, first stop the replication process:

dcr stop replication_name --all

You can stop replication of specific tables as well:

dcr stop replication_name --tables=myTable1

This will stop the source cluster from sending updates, but will not delete the replication connection. Replication can be resumed if necessary.

To completely remove the replications, use the delete command:

dcr delete replication_name

This will permanently delete the replication configuration. If replication is recreated, it will need to first synchronize the clusters, instead of resuming where it stopped before.

© 2024 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.

Last updated on Jul 13, 2024