Skip to content
Snippets Groups Projects
upgrade.md 52.54 KiB

Upgrading Synapse

Before upgrading check if any special steps are required to upgrade from the version you currently have installed to the current version of Synapse. The extra instructions that may be required are listed later in this document.

  • Check that your versions of Python and PostgreSQL are still supported.

    Synapse follows upstream lifecycles for Python and PostgreSQL, and removes support for versions which are no longer maintained.

    The website https://endoflife.date also offers convenient summaries.

  • If Synapse was installed using prebuilt packages, you will need to follow the normal process for upgrading those packages.

  • If Synapse was installed from source, then:

    1. Activate the virtualenv before upgrading. For example, if Synapse is installed in a virtualenv in ~/synapse/env then run:

      source ~/synapse/env/bin/activate
    2. If Synapse was installed using pip then upgrade to the latest version by running:

      pip install --upgrade matrix-synapse

      If Synapse was installed using git then upgrade to the latest version by running:

      git pull
      pip install --upgrade .
    3. Restart Synapse:

      ./synctl restart

To check whether your update was successful, you can check the running server version with:

# you may need to replace 'localhost:8008' if synapse is not configured
# to listen on port 8008.

curl http://localhost:8008/_synapse/admin/v1/server_version

Rolling back to older versions

Rolling back to previous releases can be difficult, due to database schema changes between releases. Where we have been able to test the rollback process, this will be noted below.

In general, you will need to undo any changes made during the upgrade process, for example:

  • pip:

    source env/bin/activate
    # replace `1.3.0` accordingly:
    pip install matrix-synapse==1.3.0
  • Debian:

    # replace `1.3.0` and `stretch` accordingly:
    wget https://packages.matrix.org/debian/pool/main/m/matrix-synapse-py3/matrix-synapse-py3_1.3.0+stretch1_amd64.deb
    dpkg -i matrix-synapse-py3_1.3.0+stretch1_amd64.deb

Upgrading to v1.xx.0

Add support for routing outbound HTTP requests via a proxy for federation

Since Synapse 1.6.0 (2019-11-26) you can set a proxy for outbound HTTP requests via http_proxy/https_proxy environment variables. This proxy was set for:

  • push
  • url previews
  • phone-home stats
  • recaptcha validation
  • CAS auth validation
  • OpenID Connect
  • Federation (checking public key revocation)

In this version we have added support for outbound requests for:

  • Outbound federation
  • Downloading remote media
  • Fetching public keys of other servers

These requests use the same proxy configuration. If you have a proxy configuration we recommend to verify the configuration. It may be necessary to adjust the no_proxy environment variable.

See using a forward proxy with Synapse documentation for details.

Upgrading to v1.39.0

Deprecation of the current third-party rules module interface

The current third-party rules module interface is deprecated in favour of the new generic modules system introduced in Synapse v1.37.0. Authors of third-party rules modules can refer to this documentation to update their modules. Synapse administrators can refer to this documentation to update their configuration once the modules they are using have been updated.

We plan to remove support for the current third-party rules interface in September 2021.

Upgrading to v1.38.0

Re-indexing of events table on Postgres databases

This release includes a database schema update which requires re-indexing one of the larger tables in the database, events. This could result in increased disk I/O for several hours or days after upgrading while the migration completes. Furthermore, because we have to keep the old indexes until the new indexes are ready, it could result in a significant, temporary, increase in disk space.

To get a rough idea of the disk space required, check the current size of one of the indexes. For example, from a psql shell, run the following sql:

SELECT pg_size_pretty(pg_relation_size('events_order_room'));

We need to rebuild four indexes, so you will need to multiply this result by four to give an estimate of the disk space required. For example, on one particular server:

synapse=# select pg_size_pretty(pg_relation_size('events_order_room'));
 pg_size_pretty
----------------
 288 MB
(1 row)

On this server, it would be wise to ensure that at least 1152MB are free.

The additional disk space will be freed once the migration completes.

SQLite databases are unaffected by this change.

Upgrading to v1.37.0

Deprecation of the current spam checker interface

The current spam checker interface is deprecated in favour of a new generic modules system. Authors of spam checker modules can refer to this documentation to update their modules. Synapse administrators can refer to this documentation to update their configuration once the modules they are using have been updated.

We plan to remove support for the current spam checker interface in August 2021.

More module interfaces will be ported over to this new generic system in future versions of Synapse.

Upgrading to v1.34.0

room_invite_state_types configuration setting

The room_invite_state_types configuration setting has been deprecated and replaced with room_prejoin_state. See the sample configuration file.

If you have set room_invite_state_types to the default value you should simply remove it from your configuration file. The default value used to be: