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.