This page describes Read Replica Nodes in Stardog - a useful feature for maintaining HA clusters.
The notion of a read replica node was introduced in Stardog 8.0.0. A read replica node runs next to the Stardog cluster and periodically requests updates. A read replica node can also respond to read-only requests, such as SPARQL queries, but it cannot service any user write requests. Similar to a standby node, a read replica node stays closely synchronized with the cluster but without disturbing the cluster with the more difficult
join event. By only drifting from full synchronization by limited time windows it allows for two important features:
The read replica node can respond to SPARQL queries with minimal impact on the cluster. Note that the query results may not be exactly the same as those returned by the cluster, since the read replica node’s databases may be slightly out of date. If this is not acceptable for a given query, then the query should be sent to the cluster.
The read replica node can safely run database and server backups while taking minimal CPU cycles from servicing user requests on cluster nodes.
Unlike a standby node, a read replica node cannot be directly upgraded to be a full node in the cluster. However, a read replica node can be upgraded to a full node in the cluster by removing its read replica configuration settings, and then re-starting the node. Although this process is not as convenient as that of promoting a standby node using the
cluster standby-join command, it allows a read replica node to serve a similar purpose to a standby node while also being available to service queries.
To start a cluster node as a read replica node simply add the following lines to
pack.standby=true pack.standby.node.sync.interval=5m pack.readReplica=true
This configures the node to be in read replica mode and to wait 5 minutes between synchronization attempts. The interval begins when the synchronization completes, e.g., if a synchronization takes 3 minutes it will be 8 minutes before the next synchronization attempt.
The synchronization interval can be increased or decreased depending on your requirements and use case. For example, if you require that the query results returned from the read relica node be no more than 2 minutes behind the data stored on the cluster, then set the
pack.standby.node.sync.interval configuration value to
2m; however, be sure to monitor the performance of all nodes in the cluster (including the read replica node) to ensure that the increased synchronization frequency does not degrade performance to an unacceptable level.
As mentioned above, a read replica node can be joined to the cluster as a full node by stopping the node, removing the above lines from the node’s
stardog.properties file, and then re-starting the node.
An example scenario where adding a read replica node to your cluster would be useful is an ecommerce recommendation system. The cluster is constantly being updated as users make purchases in the ecommerce system, and the data in the cluster must be queried to provide browsing shoppers with recommendations of related items to purchase. The recommendations provided to a browsing shopper do not need to be perfectly synchronized with the purchase data stored in the cluster, so querying a read replica node for recommendations makes sense (and removes the query load from the cluster).
Suppose that we have configured a six node cluster as described in the
Installation and Setup page. Now that we have decided to add a read replica node to this cluster, we need to configure our proxy server to route SPARQL queries to the read replica node instead of to the cluster.
Continuing with the HAProxy configuration example
Start HAProxy (or equivalent), we add the following
backend definition for our read replica node at the end of the
# the Stardog read replica backend stardog_read_replica mode http option tcpka # keep-alive # the following line returns 200 for a read replica node and # 400 for a node that is not a read replica (e.g., a standby # node or a full cluster node) option httpchk GET /admin/cluster/readreplica # the check interval can be increased or decreased depending # on your requirements and use case default-server inter 5s # replace the IP address with the corresponding node address; # maxconn value can be upgraded if you expect more concurrent # connections server stardog4 188.8.131.52:5821 maxconn 64 check
Next we update the
frontend stardog-in definition in the
haproxy.cfg file with an ACL that routes SPARQL queries to the read replica node.
frontend stardog-in mode http option tcpka # keep-alive bind *:5820 # the following lines identify any routes that end with # "/query" and send them directly to the read replica node; # if haproxy is unable to find a healthy read replica node, # the request falls through and will be routed via the # default_backend acl read_replica_down nbsrv(stardog_read_replica) lt 1 use_backend all_stardogs if read_replica_down acl query_route path -i -m end /query use_backend stardog_read_replica if query_route # the following lines identify any routes with "transaction" # in the path and send them directly to the coordinator, if # haproxy is unable to determine the coordinator all requests # will fall through and be routed via the default_backend acl transaction_route path_sub -i transaction use_backend stardog_coordinator if transaction_route default_backend all_stardogs
And finally we update the
backend all_stardogs definition in the
haproxy.cfg file, inserting
mode http before the
option tcpka line.