Replication is implemented using a push mechanism on the source side. Changes in this repository trigger the packaging and sending of the changes over to the target. The bulk of the processing, the control, and the configuration is located on the source. The root of the replication configuration is located at /hippo:configuration/hippo:modules/replication/hippo:moduleconfig.
Configuring the replication target
In order for the source to know where to replicate to, it needs to be configured with the right URL to connect to and the credentials of the (target) user to connect with.
As of brXM 15.1.0, multiple replication targets are supported.
brXM 14.x and 15.0.x (single replication target)
Below /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/targets add a node of type hipposys:moduleconfig.
Specify the url of the target replication REST service as the value of the property location. This should be something like http://host[:port]/cms/ws/replication-target.
Also specify the credentials of the target user to connect with using the properties username and password. The username and password should be of a valid (target) repository user, who is also authorized with the restuser role for the /hippo:configuration/hippo:domains/replication-rest domain (by default all users from the admin group are already authorized).
brXM 15.1.0 and later (one or multiple replication targets)
Below /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/targets add a node of type replication:target.
Specify the url of the target replication REST service as the value of the property replication:location. This should be something like http://host[:port]/cms/ws/replication-target.
Also specify the credentials of the target user to connect with using the properties replication:username and replication:password. The username and password should be of a valid (target) repository user, who is also authorized with the restuser role for the /hippo:configuration/hippo:domains/replication-rest domain (by default all users from the admin group are already authorized).
The new target node would be something like below with your values:
/hippo:configuration/hippo:modules/replication/hippo:moduleconfig/targets/targetdemo: jcr:primaryType: replication:target replication:location: http://127.0.0.1:9080/cms/ws/replication-target replication:password: admin replication:username: admin
Tweaking the replication process
As properties directly under the root of the configuration tree at /hippo:configuration/hippo:modules/replication/hippo:moduleconfig, you can tweak the following settings:
|Property name||Multi-valued||Default||Needs Restart||Description|
|monitorinterval||no||10000||no||How often the repository journal is monitored for changes, specified in milliseconds.|
|packagerinterval||no||10000||no||How often detected and queued changes are processed and sent to the target, specified in milliseconds.|
|syncbundlesize||no||100||no||Setting that controls how many replication scopes are bundled in a single replication package during a sync.|
|ignoredeventpathpatterns||yes||yes||List of regular expression patterns of events that the change monitor should ignore.|
|maxbinarysize||no||10485760 (10mb)||yes||If the size of a binary exceeds this limit, it is not replicated. Specify -1 for no limit.|
Including and excluding nodes
In order for a certain node to be replicated it needs to conform to a number of criteria. The main one is that it must be located below a path that is configured to be included, and is not located below a path that is configured to be excluded or ignored. This is configured on the node /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/metadata with the multi-valued properties excludedpaths and includedpaths. No restart is needed when changing these properties.
Excluding paths from replication not only means that the nodes below that path are not replicated from source to target, it also means that those paths are removed from the target if they are there. If you have for example comments that get added through the site and which are only added on the target, those comments will get removed by replication if they are added in a subtree below an included path, even if the path to those comments is configured to be excluded on the source. For this use case - preventing content that is not on the source to be removed from the target - you must add the path to the multi-valued ignoredpaths property on the node /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/metadata. Note that such ignored paths must be present on the source though in order to get the desired effect.
For example, let's say the target stores user comments inside the folder /content/documents/comments (e.g. /content/documents/comments/2016/01/07/usercomment1) . To prevent /content/documents/comments and all the user comments stored inside it from being removed from target by replication you must:
- Create the folder /content/documents/comments on the source.
- Add the folder /content/document/comments to both the excludedpaths and the ignoredpaths property of the node /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/metadata on the source.
To avoid that the target accepts content from an untrusted source Tomcat can be configured to use two-way SSL authentication for the replication REST service. This ensures that the connection between the source and target can only be established when valid and known certificates are used on both ends.
For information on how to setup Tomcat for this see the Tomcat SSL/TLS Configuration HOW-TO document.
Replcation SSL authentication configuration example
Example configuration enforcing the target to use SSL and validate the client certificate for accepting the source connection. A self signed certificate can be used but the server name used in the certificate must match the actual name.
To log information about connection issues configure log4j to log org.apache.cxf at level info.
Replication target configuration
As an example on how the replication target can be configured to only accept a connection from a trusted source the following Tomcat connector configuration only accepts a connection that provides a certificate in the provided truststore:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" truststoreFile="/home/hippo/.keystore" truststorePass="changeit"/>
Replication source configuration
The source can be configured to provide a certificate to the target using Java system properties. This is validated by the target using the target's trust store. Example of a source keystore configuration using Cargo systemProperties in a test environment: