Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Commit

Permalink
Merge pull request #2117 from matrix-org/erikj/remove_http_replication
Browse files Browse the repository at this point in the history
Remove HTTP replication APIs
  • Loading branch information
erikjohnston authored Apr 12, 2017
2 parents 7b41013 + 82301b6 commit bf90601
Show file tree
Hide file tree
Showing 8 changed files with 11 additions and 990 deletions.
26 changes: 4 additions & 22 deletions docs/replication.rst
Original file line number Diff line number Diff line change
Expand Up @@ -26,28 +26,10 @@ expose the append-only log to the readers should be fairly minimal.
Architecture
------------

The Replication API
~~~~~~~~~~~~~~~~~~~

Synapse will optionally expose a long poll HTTP API for extracting updates. The
API will have a similar shape to /sync in that clients provide tokens
indicating where in the log they have reached and a timeout. The synapse server
then either responds with updates immediately if it already has updates or it
waits until the timeout for more updates. If the timeout expires and nothing
happened then the server returns an empty response.

However unlike the /sync API this replication API is returning synapse specific
data rather than trying to implement a matrix specification. The replication
results are returned as arrays of rows where the rows are mostly lifted
directly from the database. This avoids unnecessary JSON parsing on the server
and hopefully avoids an impedance mismatch between the data returned and the
required updates to the datastore.

This does not replicate all the database tables as many of the database tables
are indexes that can be recovered from the contents of other tables.

The format and parameters for the api are documented in
``synapse/replication/resource.py``.
The Replication Protocol
~~~~~~~~~~~~~~~~~~~~~~~~

See ``tcp_replication.rst``


The Slaved DataStore
Expand Down
18 changes: 7 additions & 11 deletions docs/workers.rst
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ across multiple processes is a recipe for disaster, plus you should be using
postgres anyway if you care about scalability).

The workers communicate with the master synapse process via a synapse-specific
HTTP protocol called 'replication' - analogous to MySQL or Postgres style
TCP protocol called 'replication' - analogous to MySQL or Postgres style
database replication; feeding a stream of relevant data to the workers so they
can be kept in sync with the main synapse process and database state.

Expand All @@ -21,16 +21,11 @@ To enable workers, you need to add a replication listener to the master synapse,
listeners:
- port: 9092
bind_address: '127.0.0.1'
type: http
tls: false
x_forwarded: false
resources:
- names: [replication]
compress: false
type: replication

Under **no circumstances** should this replication API listener be exposed to the
public internet; it currently implements no authentication whatsoever and is
unencrypted HTTP.
unencrypted.

You then create a set of configs for the various worker processes. These should be
worker configuration files should be stored in a dedicated subdirectory, to allow
Expand All @@ -50,14 +45,16 @@ e.g. the HTTP listener that it provides (if any); logging configuration; etc.
You should minimise the number of overrides though to maintain a usable config.

You must specify the type of worker application (worker_app) and the replication
endpoint that it's talking to on the main synapse process (worker_replication_url).
endpoint that it's talking to on the main synapse process (worker_replication_host
and worker_replication_port).

For instance::

worker_app: synapse.app.synchrotron

# The replication listener on the synapse to talk to.
worker_replication_url: http://127.0.0.1:9092/_synapse/replication
worker_replication_host: 127.0.0.1
worker_replication_port: 9092

worker_listeners:
- type: http
Expand Down Expand Up @@ -95,4 +92,3 @@ To manipulate a specific worker, you pass the -w option to synctl::
All of the above is highly experimental and subject to change as Synapse evolves,
but documenting it here to help folks needing highly scalable Synapses similar
to the one running matrix.org!

4 changes: 0 additions & 4 deletions synapse/app/homeserver.py
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,6 @@
from synapse.util.logcontext import LoggingContext, PreserveLoggingContext
from synapse.metrics import register_memory_metrics, get_metrics_for
from synapse.metrics.resource import MetricsResource, METRICS_PREFIX
from synapse.replication.resource import ReplicationResource, REPLICATION_PREFIX
from synapse.replication.tcp.resource import ReplicationStreamProtocolFactory
from synapse.federation.transport.server import TransportLayerServer

Expand Down Expand Up @@ -167,9 +166,6 @@ def _listener_http(self, config, listener_config):
if name == "metrics" and self.get_config().enable_metrics:
resources[METRICS_PREFIX] = MetricsResource(self)

if name == "replication":
resources[REPLICATION_PREFIX] = ReplicationResource(self)

if WEB_CLIENT_PREFIX in resources:
root_resource = RootRedirect(WEB_CLIENT_PREFIX)
else:
Expand Down
60 changes: 0 additions & 60 deletions synapse/replication/expire_cache.py

This file was deleted.

59 changes: 0 additions & 59 deletions synapse/replication/presence_resource.py

This file was deleted.

54 changes: 0 additions & 54 deletions synapse/replication/pusher_resource.py

This file was deleted.

Loading

0 comments on commit bf90601

Please sign in to comment.