1
0

replication.rst 1.6 KB

12345678910111213141516171819202122232425262728293031323334353637383940
  1. Replication Architecture
  2. ========================
  3. Motivation
  4. ----------
  5. We'd like to be able to split some of the work that synapse does into multiple
  6. python processes. In theory multiple synapse processes could share a single
  7. postgresql database and we'd scale up by running more synapse processes.
  8. However much of synapse assumes that only one process is interacting with the
  9. database, both for assigning unique identifiers when inserting into tables,
  10. notifying components about new updates, and for invalidating its caches.
  11. So running multiple copies of the current code isn't an option. One way to
  12. run multiple processes would be to have a single writer process and multiple
  13. reader processes connected to the same database. In order to do this we'd need
  14. a way for the reader process to invalidate its in-memory caches when an update
  15. happens on the writer. One way to do this is for the writer to present an
  16. append-only log of updates which the readers can consume to invalidate their
  17. caches and to push updates to listening clients or pushers.
  18. Synapse already stores much of its data as an append-only log so that it can
  19. correctly respond to /sync requests so the amount of code changes needed to
  20. expose the append-only log to the readers should be fairly minimal.
  21. Architecture
  22. ------------
  23. The Replication Protocol
  24. ~~~~~~~~~~~~~~~~~~~~~~~~
  25. See ``tcp_replication.rst``
  26. The Slaved DataStore
  27. ~~~~~~~~~~~~~~~~~~~~
  28. There are read-only version of the synapse storage layer in
  29. ``synapse/replication/slave/storage`` that use the response of the replication
  30. API to invalidate their caches.