summary refs log tree commit diff
path: root/docs/replication.md
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.md
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.md')
-rw-r--r--docs/replication.md37
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.