2021-06-03 15:06:03 +02:00
|
|
|
# Purge History API
|
2016-07-28 15:56:09 +02:00
|
|
|
|
|
|
|
The purge history API allows server admins to purge historic events from their
|
|
|
|
database, reclaiming disk space.
|
|
|
|
|
|
|
|
Depending on the amount of history being purged a call to the API may take
|
|
|
|
several minutes or longer. During this period users will not be able to
|
|
|
|
paginate further back in the room from the point being purged from.
|
|
|
|
|
2020-02-12 16:39:40 +01:00
|
|
|
Note that Synapse requires at least one message in each room, so it will never
|
|
|
|
delete the last message in a room.
|
2020-02-11 18:56:04 +01:00
|
|
|
|
2018-03-02 00:20:54 +01:00
|
|
|
The API is:
|
2016-07-28 15:56:09 +02:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
```
|
|
|
|
POST /_synapse/admin/v1/purge_history/<room_id>[/<event_id>]
|
|
|
|
```
|
2016-07-28 15:56:09 +02:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
To use it, you will need to authenticate by providing an `access_token` for a
|
|
|
|
server admin: [Admin API](README.rst)
|
2018-02-08 19:44:52 +01:00
|
|
|
|
|
|
|
By default, events sent by local users are not deleted, as they may represent
|
|
|
|
the only copies of this content in existence. (Events sent by remote users are
|
2018-03-15 12:05:42 +01:00
|
|
|
deleted.)
|
2018-02-08 19:44:52 +01:00
|
|
|
|
2018-03-15 12:05:42 +01:00
|
|
|
Room state data (such as joins, leaves, topic) is always preserved.
|
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
To delete local message events as well, set `delete_local_events` in the body:
|
2018-02-08 19:44:52 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
```
|
|
|
|
{
|
|
|
|
"delete_local_events": true
|
|
|
|
}
|
|
|
|
```
|
2018-03-02 00:20:54 +01:00
|
|
|
|
|
|
|
The caller must specify the point in the room to purge up to. This can be
|
|
|
|
specified by including an event_id in the URI, or by setting a
|
2021-06-03 15:06:03 +02:00
|
|
|
`purge_up_to_event_id` or `purge_up_to_ts` in the request body. If an event
|
2018-03-02 00:20:54 +01:00
|
|
|
id is given, that event (and others at the same graph depth) will be retained.
|
2021-06-03 15:06:03 +02:00
|
|
|
If `purge_up_to_ts` is given, it should be a timestamp since the unix epoch,
|
2018-03-02 00:20:54 +01:00
|
|
|
in milliseconds.
|
2018-03-08 12:47:28 +01:00
|
|
|
|
|
|
|
The API starts the purge running, and returns immediately with a JSON body with
|
|
|
|
a purge id:
|
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
```json
|
|
|
|
{
|
|
|
|
"purge_id": "<opaque id>"
|
|
|
|
}
|
|
|
|
```
|
2018-03-08 12:47:28 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
## Purge status query
|
2018-03-08 12:47:28 +01:00
|
|
|
|
|
|
|
It is possible to poll for updates on recent purges with a second API;
|
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
```
|
|
|
|
GET /_synapse/admin/v1/purge_history_status/<purge_id>
|
|
|
|
```
|
2018-03-08 12:47:28 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
Again, you will need to authenticate by providing an `access_token` for a
|
2020-06-05 18:31:05 +02:00
|
|
|
server admin.
|
|
|
|
|
|
|
|
This API returns a JSON body like the following:
|
2018-03-08 12:47:28 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
```json
|
|
|
|
{
|
|
|
|
"status": "active"
|
|
|
|
}
|
|
|
|
```
|
2018-03-08 12:47:28 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
The status will be one of `active`, `complete`, or `failed`.
|
2018-11-18 19:37:56 +01:00
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
## Reclaim disk space (Postgres)
|
2018-11-18 19:37:56 +01:00
|
|
|
|
|
|
|
To reclaim the disk space and return it to the operating system, you need to run
|
|
|
|
`VACUUM FULL;` on the database.
|
|
|
|
|
2021-06-03 15:06:03 +02:00
|
|
|
<https://www.postgresql.org/docs/current/sql-vacuum.html>
|