Skip to content

Commit c24bbb8

Browse files
committed
Describe controlled route flow
1 parent 01c78b8 commit c24bbb8

File tree

1 file changed

+20
-5
lines changed

1 file changed

+20
-5
lines changed

docs/developers/replication/index.md

Lines changed: 20 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -204,15 +204,30 @@ replication:
204204

205205
Note that in this example, we are using loop back addresses, which can be a convenient way to run multiple nodes on a single machine for testing and development.
206206

207-
#### Explicit Subscriptions
207+
### Controlled Replication Flow
208208

209-
#### Managing Node Connections and Subscriptions in Harper
209+
By default, Harper will replicate all data in all databases, with symmetric bi-directional flow between nodes. However, there are times when you may want to control the replication flow between nodes, and dictate that data should only be replicated in one direction between certain nodes. This can be done by setting the direction in the `replicates` attribute of the node definition when adding the node or configuring the replication route. For example, to configure a node to only send data to `node-two`, and only receive data from `node-three` you can add the following to the replication route:
210210

211-
By default, Harper automatically handles connections and subscriptions between nodes, ensuring data consistency across your cluster. It even uses data routing to manage node failures. But if you want more control, you can manage these connections manually by explicitly subscribing to nodes. This is useful for advanced configurations, testing, or debugging.
211+
```yaml
212+
replication:
213+
databases:
214+
- data
215+
routes:
216+
- name: node-two
217+
replicates:
218+
sends: true
219+
receives: false
220+
- name: node-three
221+
replicates:
222+
sends: false
223+
receives: true
224+
```
212225

213-
#### Important Notes on Explicit Subscriptions
226+
When using controlled flow replication, you will typically have different route configurations for each node to every other node. In that case, typically you do want to ensure that you are _not_ replicating the `system` database, since the `system` database containes the node configurations, and replicating the `system` database will cause all nodes to be replicated and have identical route configurations.
227+
228+
#### Explicit Subscriptions
214229

215-
If you choose to manage subscriptions manually, Harper will no longer handle data consistency for you. This means there’s no guarantee that all nodes will have consistent data if subscriptions don’t fully replicate in all directions. If a node goes down, it’s possible that some data wasn’t replicated before the failure.
230+
By default, Harper automatically handles connections and subscriptions between nodes, ensuring data consistency across your cluster. It even uses data routing to manage node failures. However, you can manage these connections manually by explicitly subscribing to nodes. This should _not_ be used for production replication and should be avoided and exists only for testing, debugging, and legacy migration. This will likely be removed in V5. If you choose to manage subscriptions manually, Harper will no longer handle data consistency for you. This means there’s no guarantee that all nodes will have consistent data if subscriptions don’t fully replicate in all directions. If a node goes down, it’s possible that some data wasn’t replicated before the failure. If you want single direction replication, you can use controlled replication flow described above.
216231

217232
#### How to Subscribe to Nodes
218233

0 commit comments

Comments
 (0)