How can I check if data is replicated between primary and DR?
You can check the output of
gstatusgraph on both primary and DR. The count for vertices and edges should match. Note that in case there are running loading job DR might be having lower count, in that case check again when the loading job is done.
Why I’m not seeing any loading job declared in DR?
A Loading jobs are not replicated over DR, however the data loaded by these loading jobs is replicated over DR.
I’ve run a
DROP ALL on primary and now new added data is not replicated in DR
DROP ALL command will stop Cross Region Replication, you will need to restore re-establish the feature again. Below is a list of all commands and operation that will stop Cross Region Replication:
gsql drop allwhich clears all data and schema
gsql clear graph storewhich clears only data
gsql --resetwhich clears all data, schema and users even reset the password of the default tigergraph.
gsql import graph
gsql export graph
GSQL is failing to replay a replica, and it’s reporting UNAUTHORIZED error?*
A: It’s most likely that primary and DR have different password for the same tigergraph user and this could be due to the fact that you enabled Cross Region Replication without restoring the gbar backup in DR (since you did not have any data) but DR was installed with a different password than primary. Make sure DR and primary have the same tigergraph password before enabling Cross Region Replication.
What happens if DR is down, unavailable or under scheduled maintenance (e.g. VM Motion)?
Nothing will happen, as soon as DR is back online Kafka MirrorMaker will replicate the Kafka Topic and GSQL will start replaying the replicas from where it left. Of course DR cannot be unavailable for an indefinite time, in order to automatically recover it has to be down within the Kafka Topic retention hours which by default is set to 168hrs (7 days). You can tune this parameter based on your need by running
gadmin config set Kafka.RetentionHours <value_in_hrs>
Can I have multiple DRs?
A: Yes, just enable Cross Region Replication on the other DR you may want to have as you did with your first DR. There is limitation in numbers of DRs that you can have.
Q: How will my application write to the new primary after DR failover?
It’s suggested that you handle this with an application load balancer where you can configure the DR IP hosts list (e.g. if you are using NGINX you can add the DR hosts list in the upstream section). When the Load Balancer fails the health check on the current primary it will re-route the traffic to the DR host list. You should then manually fail over to the DR cluster.