diff options
author | dstipp <dstipp@users.noreply.github.com> | 2019-09-17 07:55:29 -0400 |
---|---|---|
committer | Richard van der Hoff <1389908+richvdh@users.noreply.github.com> | 2019-09-17 12:55:29 +0100 |
commit | 379d2a8c3918557bacdadea6b508bddd1ce20eaf (patch) | |
tree | 8b8e3b016ce54d9d2e76a598931322ee7bd79754 /docs/replication.md | |
parent | Fix race condition in room stats. (#6029) (diff) | |
download | synapse-379d2a8c3918557bacdadea6b508bddd1ce20eaf.tar.xz |
(#5849) Convert rst to markdown (#6040)
Converting some of the rst documentation to markdown. Attempted to preserve whitespace and line breaks to minimize cosmetic change.
Diffstat (limited to 'docs/replication.md')
-rw-r--r-- | docs/replication.md | 37 |
1 files changed, 37 insertions, 0 deletions
diff --git a/docs/replication.md b/docs/replication.md new file mode 100644 index 0000000000..ed88233157 --- /dev/null +++ b/docs/replication.md @@ -0,0 +1,37 @@ +# Replication Architecture + +## Motivation + +We'd like to be able to split some of the work that synapse does into +multiple python processes. In theory multiple synapse processes could +share a single postgresql database and we\'d scale up by running more +synapse processes. However much of synapse assumes that only one process +is interacting with the database, both for assigning unique identifiers +when inserting into tables, notifying components about new updates, and +for invalidating its caches. + +So running multiple copies of the current code isn't an option. One way +to run multiple processes would be to have a single writer process and +multiple reader processes connected to the same database. In order to do +this we'd need a way for the reader process to invalidate its in-memory +caches when an update happens on the writer. One way to do this is for +the writer to present an append-only log of updates which the readers +can consume to invalidate their caches and to push updates to listening +clients or pushers. + +Synapse already stores much of its data as an append-only log so that it +can correctly respond to `/sync` requests so the amount of code changes +needed to expose the append-only log to the readers should be fairly +minimal. + +## Architecture + +### The Replication Protocol + +See [tcp_replication.md](tcp_replication.md) + +### The Slaved DataStore + +There are read-only version of the synapse storage layer in +`synapse/replication/slave/storage` that use the response of the +replication API to invalidate their caches. |