You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-docker-ansible-deploy/docs/maintenance-synapse.md

5.1 KiB

Synapse maintenance

This document shows you how to perform various maintenance tasks related to the Synapse chat server.

Table of contents:

Purging old data with the Purge History API

You can use the Purge History API to delete in-use (but old) data.

This is destructive (especially for non-federated rooms), because it means people will no longer have access to history past a certain point.

Synapse's Purge History API can be used to purge on a per-room basis.

To make use of this API, you'll need an admin access token first. You can find your access token in the setting of some clients (like Element). Alternatively, you can log in and obtain a new access token like this:

curl \
--data '{"identifier": {"type": "m.id.user", "user": "YOUR_MATRIX_USERNAME" }, "password": "YOUR_MATRIX_PASSWORD", "type": "m.login.password", "device_id": "Synapse-Purge-History-API"}' \
https://matrix.DOMAIN/_matrix/client/r0/login

Follow the Purge History API documentation page for the actual purging instructions.

After deleting data, you may wish to run a FULL Postgres VACUUM.

Compressing state with rust-synapse-compress-state

rust-synapse-compress-state can be used to optimize some _state tables used by Synapse.

This tool should be safe to use (even when Synapse is running), but it's always a good idea to make Postgres backups first.

To ask the playbook to run rust-synapse-compress-state, execute:

ansible-playbook -i inventory/hosts setup.yml --tags=rust-synapse-compress-state

By default, all rooms with more than 100000 state group rows will be compressed. If you need to adjust this, pass: --extra-vars='matrix_synapse_rust_synapse_compress_state_min_state_groups_required=SOME_NUMBER_HERE' to the command above.

After state compression, you may wish to run a FULL Postgres VACUUM.

Purging unused data with synapse-janitor

NOTE: There are reports that synapse-janitor is dangerous to use and causes database corruption. You may wish to refrain from using it.

When you leave and forget a room, Synapse can clean up its data, but currently doesn't. This unused and unreachable data remains in your database forever.

There are external tools (like synapse-janitor), which are meant to solve this problem.

To ask the playbook to run synapse-janitor, execute:

ansible-playbook -i inventory/hosts setup.yml --tags=run-postgres-synapse-janitor,start

Note: this will automatically stop Synapse temporarily and restart it later.

Running synapse-janitor potentially deletes a lot of data from the Postgres database. You may wish to run a FULL Postgres VACUUM after that.

Browse and manipulate the database

When the matrix admin API and the other tools do not provide a more convenient way, having a look at synapse's postgresql database can satisfy a lot of admins' needs. First, set up an SSH tunnel to your matrix server (skip if it is your local machine):

# you may replace 1799 with an arbitrary port unbound on both machines
ssh -L 1799:localhost:1799 matrix.DOMAIN

Then start up an ephemeral adminer container on the Matrix server, connecting it to the matrix network and linking the postgresql container:

docker run --rm --publish 1799:8080 --link matrix-postgres --net matrix adminer

You should then be able to browse the adminer database administration GUI at http://localhost:1799/ after entering your DB credentials (found in the host_vars or on the server in {{matrix_synapse_config_dir_path}}/homeserver.yaml under database.args)

⚠️ Be very careful with this, there is no undo for impromptu DB operations.