purge_history_api.rst 2.0 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071
  1. Purge History API
  2. =================
  3. The purge history API allows server admins to purge historic events from their
  4. database, reclaiming disk space.
  5. Depending on the amount of history being purged a call to the API may take
  6. several minutes or longer. During this period users will not be able to
  7. paginate further back in the room from the point being purged from.
  8. The API is:
  9. ``POST /_synapse/admin/v1/purge_history/<room_id>[/<event_id>]``
  10. including an ``access_token`` of a server admin.
  11. By default, events sent by local users are not deleted, as they may represent
  12. the only copies of this content in existence. (Events sent by remote users are
  13. deleted.)
  14. Room state data (such as joins, leaves, topic) is always preserved.
  15. To delete local message events as well, set ``delete_local_events`` in the body:
  16. .. code:: json
  17. {
  18. "delete_local_events": true
  19. }
  20. The caller must specify the point in the room to purge up to. This can be
  21. specified by including an event_id in the URI, or by setting a
  22. ``purge_up_to_event_id`` or ``purge_up_to_ts`` in the request body. If an event
  23. id is given, that event (and others at the same graph depth) will be retained.
  24. If ``purge_up_to_ts`` is given, it should be a timestamp since the unix epoch,
  25. in milliseconds.
  26. The API starts the purge running, and returns immediately with a JSON body with
  27. a purge id:
  28. .. code:: json
  29. {
  30. "purge_id": "<opaque id>"
  31. }
  32. Purge status query
  33. ------------------
  34. It is possible to poll for updates on recent purges with a second API;
  35. ``GET /_synapse/admin/v1/purge_history_status/<purge_id>``
  36. (again, with a suitable ``access_token``). This API returns a JSON body like
  37. the following:
  38. .. code:: json
  39. {
  40. "status": "active"
  41. }
  42. The status will be one of ``active``, ``complete``, or ``failed``.
  43. Reclaim disk space (Postgres)
  44. -----------------------------
  45. To reclaim the disk space and return it to the operating system, you need to run
  46. `VACUUM FULL;` on the database.
  47. https://www.postgresql.org/docs/current/sql-vacuum.html