Hippo offers a solution for replication between repositories. Replication can for instance be useful when you want to separate your external-facing content service from your intranet-hosted editing environment.
The public website is backed by a read-only repository that lives inside the organisation's DMZ. The CMS is hosted behind a firewall and backed by a repository that is outside the public network.
Replication happens automatically when editors publish changes using the CMS. At that time the replication source repository cluster pushes out the changes to the replication target repository cluster. In the case where the target is down, the source will suspend the replication process for the time being and automatically resume and send the backlog of changes when the target comes up again.
For the source to communicate with the target cluster, the target needs to be fronted by a load-balancer. The source sends its replication packages to the load-balancer which forwards the request to a live repository node.
Not any and all changes to the repository are replicated. Changes to document types and changes to the CMS configuration are not replicated for instance. Although this can easily be customized, preview documents and HST preview configurations are not replicated either.
By default the following repository subtrees are included in replication:
- /content: all documents, assets, images, and other content stored here as part of plugins. Only live published documents will appear on the target.
- /hst:hst: HST configuration is replicated with the exception of site preview configuration which is only relevant to the Channel Editor.
- /targeting: Relevance Module settings (persona's, characteristics, etc.)
If you have your own subsystem built on top of the repository, you can write a plugin for the replication engine to allow your content to be replicated.
Read more about replication on the following pages: