summary refs log tree commit diff
path: root/docs/replication.rst
diff options
context:
space:
mode:
authordstipp <dstipp@users.noreply.github.com>2019-09-17 07:55:29 -0400
committerRichard van der Hoff <1389908+richvdh@users.noreply.github.com>2019-09-17 12:55:29 +0100
commit379d2a8c3918557bacdadea6b508bddd1ce20eaf (patch)
tree8b8e3b016ce54d9d2e76a598931322ee7bd79754 /docs/replication.rst
parentFix race condition in room stats. (#6029) (diff)
downloadsynapse-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.rst')
-rw-r--r--docs/replication.rst40
1 files changed, 0 insertions, 40 deletions
diff --git a/docs/replication.rst b/docs/replication.rst
deleted file mode 100644

index 310abb3488..0000000000 --- a/docs/replication.rst +++ /dev/null
@@ -1,40 +0,0 @@ -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.rst`` - - -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.