postgres.rst 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164
  1. Using Postgres
  2. --------------
  3. Postgres version 9.5 or later is known to work.
  4. Install postgres client libraries
  5. =================================
  6. Synapse will require the python postgres client library in order to connect to
  7. a postgres database.
  8. * If you are using the `matrix.org debian/ubuntu
  9. packages <../INSTALL.md#matrixorg-packages>`_,
  10. the necessary libraries will already be installed.
  11. * For other pre-built packages, please consult the documentation from the
  12. relevant package.
  13. * If you installed synapse `in a virtualenv
  14. <../INSTALL.md#installing-from-source>`_, you can install the library with::
  15. ~/synapse/env/bin/pip install matrix-synapse[postgres]
  16. (substituting the path to your virtualenv for ``~/synapse/env``, if you used a
  17. different path). You will require the postgres development files. These are in
  18. the ``libpq-dev`` package on Debian-derived distributions.
  19. Set up database
  20. ===============
  21. Assuming your PostgreSQL database user is called ``postgres``, create a user
  22. ``synapse_user`` with::
  23. su - postgres
  24. createuser --pwprompt synapse_user
  25. Before you can authenticate with the ``synapse_user``, you must create a
  26. database that it can access. To create a database, first connect to the database
  27. with your database user::
  28. su - postgres
  29. psql
  30. and then run::
  31. CREATE DATABASE synapse
  32. ENCODING 'UTF8'
  33. LC_COLLATE='C'
  34. LC_CTYPE='C'
  35. template=template0
  36. OWNER synapse_user;
  37. This would create an appropriate database named ``synapse`` owned by the
  38. ``synapse_user`` user (which must already have been created as above).
  39. Note that the PostgreSQL database *must* have the correct encoding set (as
  40. shown above), otherwise it will not be able to store UTF8 strings.
  41. You may need to enable password authentication so ``synapse_user`` can connect
  42. to the database. See https://www.postgresql.org/docs/11/auth-pg-hba-conf.html.
  43. Tuning Postgres
  44. ===============
  45. The default settings should be fine for most deployments. For larger scale
  46. deployments tuning some of the settings is recommended, details of which can be
  47. found at https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server.
  48. In particular, we've found tuning the following values helpful for performance:
  49. - ``shared_buffers``
  50. - ``effective_cache_size``
  51. - ``work_mem``
  52. - ``maintenance_work_mem``
  53. - ``autovacuum_work_mem``
  54. Note that the appropriate values for those fields depend on the amount of free
  55. memory the database host has available.
  56. Synapse config
  57. ==============
  58. When you are ready to start using PostgreSQL, edit the ``database`` section in
  59. your config file to match the following lines::
  60. database:
  61. name: psycopg2
  62. args:
  63. user: <user>
  64. password: <pass>
  65. database: <db>
  66. host: <host>
  67. cp_min: 5
  68. cp_max: 10
  69. All key, values in ``args`` are passed to the ``psycopg2.connect(..)``
  70. function, except keys beginning with ``cp_``, which are consumed by the twisted
  71. adbapi connection pool.
  72. Porting from SQLite
  73. ===================
  74. Overview
  75. ~~~~~~~~
  76. The script ``synapse_port_db`` allows porting an existing synapse server
  77. backed by SQLite to using PostgreSQL. This is done in as a two phase process:
  78. 1. Copy the existing SQLite database to a separate location (while the server
  79. is down) and running the port script against that offline database.
  80. 2. Shut down the server. Rerun the port script to port any data that has come
  81. in since taking the first snapshot. Restart server against the PostgreSQL
  82. database.
  83. The port script is designed to be run repeatedly against newer snapshots of the
  84. SQLite database file. This makes it safe to repeat step 1 if there was a delay
  85. between taking the previous snapshot and being ready to do step 2.
  86. It is safe to at any time kill the port script and restart it.
  87. Using the port script
  88. ~~~~~~~~~~~~~~~~~~~~~
  89. Firstly, shut down the currently running synapse server and copy its database
  90. file (typically ``homeserver.db``) to another location. Once the copy is
  91. complete, restart synapse. For instance::
  92. ./synctl stop
  93. cp homeserver.db homeserver.db.snapshot
  94. ./synctl start
  95. Copy the old config file into a new config file::
  96. cp homeserver.yaml homeserver-postgres.yaml
  97. Edit the database section as described in the section *Synapse config* above
  98. and with the SQLite snapshot located at ``homeserver.db.snapshot`` simply run::
  99. synapse_port_db --sqlite-database homeserver.db.snapshot \
  100. --postgres-config homeserver-postgres.yaml
  101. The flag ``--curses`` displays a coloured curses progress UI.
  102. If the script took a long time to complete, or time has otherwise passed since
  103. the original snapshot was taken, repeat the previous steps with a newer
  104. snapshot.
  105. To complete the conversion shut down the synapse server and run the port
  106. script one last time, e.g. if the SQLite database is at ``homeserver.db``
  107. run::
  108. synapse_port_db --sqlite-database homeserver.db \
  109. --postgres-config homeserver-postgres.yaml
  110. Once that has completed, change the synapse config to point at the PostgreSQL
  111. database configuration file ``homeserver-postgres.yaml``::
  112. ./synctl stop
  113. mv homeserver.yaml homeserver-old-sqlite.yaml
  114. mv homeserver-postgres.yaml homeserver.yaml
  115. ./synctl start
  116. Synapse should now be running against PostgreSQL.