postgres.rst 4.7 KB

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