Replication
Danger
This is a beta feature. Production use is highly discouraged.
The component Sync provides the ability to replicate data between Cloudrexx websites.
Architecture
The Sync component listens to model changes and pushes them to any configured remote (another Cloudrexx installation having Sync set up) through the RESTful-API (DataAccess). For proper foreign key handling, the Sync component injects a wrapper command (called sync
) on top of the RESTful-API command v1
. Meaning, instead of pushing data directly to /api/v1/<outputModule>/<dataAccessName>/<elementId>
on the remote, data is pushed to /api/sync/v1/<outputModule>/<dataAccessName>/<elementId>
(note the endpoint /sync
) instead.
Supported DataSource
The Sync component does currently only support the replication of the DataSource DoctrineRepository
.
Setup
To enable the replication of model data two steps have to be taken:
Enable RESTful-API on Replica
On the Cloudrexx installation that will act as the replica, do as follows:
-
Create an API endpoint for the model that shall be replicated:
Note
Replace
MODEL
by the FQCN of the model to replicate. E.g.:Cx\\Core\\Routing\\Model\\Entity\\RewriteRule
ReplaceENDPOINT
by a unique name to identify the endpoint. E.g.:RewriteRule
-
Create a new API-Key (under Administration > RESTful API) and assign the newly created endpoint (e.g.
RewriteRule
) having write access
Enable Sync on Primary
On the Cloudrexx installation that will act as the primary, do as follows:
-
Create the same API endpoint as the one created on the replica:
Note
Replace
MODEL
andENDPOINT
by the same values used on the replica. -
Enable replication of the newly created endpoint:
Note
Replace
MODEL
by the same value used to create the endpoint. -
Register the replica:
Note
Replace
HOST
by the domain name of the replica (for local environments usingcx env
see Connect multiple ENVs to each other).
ReplaceAPI_KEY
by the previously generated API-Key on the replica. -
Enable replication of the newly created endpoint to the replica:
Note
Replace
MODEL
by the same value used to create the endpoint.
ReplaceHOST
by the name of the replica (must be identical to the one used in the previous step).
Special Case: Calendar
As the model of the Calendar component is not purely a DoctrineRepository DataSource (Remember: DoctrineRepository is the only supported DataSource), but instead a mix of LegacyDatabaseRepository and DoctrineRepository, the setup is a bit different.
-
On the replica do as follows:
- Add a new API-Key and assign all
calendar-*
endpoints (with write access)
- Add a new API-Key and assign all
-
On the primary do as follows:
- Enable endpoint (
calendar-event
) for replication:
- Enable publishing function in Calendar component:
- Register the replica:
Note
Replace
HOST
by the domain name of the replica (for local environments usingcx env
see Connect multiple ENVs to each other).
ReplaceAPI_KEY
by the previously generated API-Key on the replica.- Register replica as publishing-target in Calendar component:
Note
Replace
HOST
by the name of the replica (must be identical to the one used in the previous step). - Enable endpoint (
Bidirectional Replication
Note
For easier understanding the terms primary and replica refer to the Cloudrexx installations acting as primary and replica of the initial instructions from above. Meaning that when setting up the bidirectional replication (according to the following instructions) the term primary technically refers to the installation acting as the replica and replica to the installation acting a primary.
To enable bidirectional replication, simply set the replication up the other way round. Meaning:
- Create a new API-Key (but this time on primary) and assign the previously created endpoint (e.g.
RewriteRule
) having write access - Enable synchronization of the endpoint on the replica
- Register the primary on the replica as replication target
- On the replica, enable replication of the endpoint to primary
Important
Bidirectional replication only works properly, if the HOST
on both sides are set to the main domain (configuration option Main domain under Administration > Global Configuration > System) of the other side.
Deregistration
Deregistration of a replica involves the following steps:
Flush data from replica
Note
This step can be skipped, in case the replicated data should be kept on the replica after deregistration.
To remove any replicated data from the replica do:
TODO
Document process to remove replicated data from replica
Disable RESTful-API on replica
TODO
Document process to disable RESTful-API on replica
Deregister replica from primary
Tip
To completely purge a replica from a primary do:
Note
Replace HOST
by the name of the replica
Special Case: Calendar
Remove replica from primary:
Note
Replace HOST
by the name of the replica