Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Remove nuke-room-from-db.sh script #3888

Merged
merged 2 commits into from
Sep 17, 2018
Merged

Remove nuke-room-from-db.sh script #3888

merged 2 commits into from
Sep 17, 2018

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Sep 17, 2018

The problem with this script is that it is largely untested, entirely
unmaintained, and running it is likely to make your synapse blow up in
exciting ways.

For example, it leaves a bunch of tables with dead values in it, like
event_to_state_groups.

Having it here sends a message that it is a supported part of
synapse, which is absolutely not the case.

The problem with this script is that it is largely untested, entirely
unmaintained, and running it is likely to make your synapse blow up in
exciting ways.

For example, it leaves a bunch of tables with dead values in it, like
event_to_state_groups.

Having it here sends a message that it is a supported part of
synapse, which is absolutely not the case.
@jcgruenhage
Copy link
Contributor

I probably would not have run this in the past, if I had known how unsupported it is. On the other hand, in the cases when I used it, it got my synapse back up and running after rooms got messed up somehow.

@richvdh richvdh requested a review from a team September 17, 2018 10:57
Copy link
Contributor

@hawkowl hawkowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes pls

@hawkowl hawkowl merged commit c6363f7 into develop Sep 17, 2018
@hawkowl hawkowl deleted the rav/nuke_nuke_rooms branch September 20, 2018 14:01
hawkowl added a commit that referenced this pull request Sep 24, 2018
Features
--------

- Python 3.5 and 3.6 support is now in beta.
([\#3576](#3576))
- Implement `event_format` filter param in `/sync`
([\#3790](#3790))
- Add synapse_admin_mau:registered_reserved_users metric to expose
number of real reaserved users
([\#3846](#3846))

Bugfixes
--------

- Remove connection ID for replication prometheus metrics, as it creates
a large number of new series.
([\#3788](#3788))
- guest users should not be part of mau total
([\#3800](#3800))
- Bump dependency on pyopenssl 16.x, to avoid incompatibility with
recent Twisted.
([\#3804](#3804))
- Fix existing room tags not coming down sync when joining a room
([\#3810](#3810))
- Fix jwt import check
([\#3824](#3824))
- fix VOIP crashes under Python 3 (#3821)
([\#3835](#3835))
- Fix manhole so that it works with latest openssh clients
([\#3841](#3841))
- Fix outbound requests occasionally wedging, which can result in
federation breaking between servers.
([\#3845](#3845))
- Show heroes if room name/canonical alias has been deleted
([\#3851](#3851))
- Fix handling of redacted events from federation
([\#3859](#3859))
-  ([\#3874](#3874))
- Mitigate outbound federation randomly becoming wedged
([\#3875](#3875))

Internal Changes
----------------

- CircleCI tests now run on the potential merge of a PR.
([\#3704](#3704))
- http/ is now ported to Python 3.
([\#3771](#3771))
- Improve human readable error messages for threepid
registration/account update
([\#3789](#3789))
- Make /sync slightly faster by avoiding needless copies
([\#3795](#3795))
- handlers/ is now ported to Python 3.
([\#3803](#3803))
- Limit the number of PDUs/EDUs per federation transaction
([\#3805](#3805))
- Only start postgres instance for postgres tests on Travis CI
([\#3806](#3806))
- tests/ is now ported to Python 3.
([\#3808](#3808))
- crypto/ is now ported to Python 3.
([\#3822](#3822))
- rest/ is now ported to Python 3.
([\#3823](#3823))
- add some logging for the keyring queue
([\#3826](#3826))
- speed up lazy loading by 2-3x
([\#3827](#3827))
- Improved Dockerfile to remove build requirements after building
reducing the image size.
([\#3834](#3834))
- Disable lazy loading for incremental syncs for now
([\#3840](#3840))
- federation/ is now ported to Python 3.
([\#3847](#3847))
- Log when we retry outbound requests
([\#3853](#3853))
- Removed some excess logging messages.
([\#3855](#3855))
- Speed up purge history for rooms that have been previously purged
([\#3856](#3856))
- Refactor some HTTP timeout code.
([\#3857](#3857))
- Fix running merged builds on CircleCI
([\#3858](#3858))
- Fix typo in replication stream exception.
([\#3860](#3860))
- Add in flight real time metrics for Measure blocks
([\#3871](#3871))
- Disable buffering and automatic retrying in treq requests to prevent
timeouts. ([\#3872](#3872))
- mention jemalloc in the README
([\#3877](#3877))
- Remove unmaintained "nuke-room-from-db.sh" script
([\#3888](#3888))
@rubo77
Copy link
Contributor

rubo77 commented Oct 1, 2018

If i look at the database structure: #934

I think it is easy:

  1. delete all entries in event_to_state_groups that match entries.entry_id with the key event_to_state_groups.entry_id

  2. delete entries in event_to_state_groups

      SELECT * FROM event_to_state_groups s, events e WHERE s.event_id=e.event_id AND e.room_id like '%jGUBNvBzjGyQyKKMJV:matrix.org'
    

how do I delete only those entries now?

@richvdh
Copy link
Member Author

richvdh commented Oct 1, 2018

none of that addresses the fact that we're not able to support and test it. I suggest you maintain your own sql script.

@rubo77
Copy link
Contributor

rubo77 commented Oct 1, 2018

I will :)

Delete data concerning only the room would be

 # (untested!) 
 DELETE 
    FROM event_to_state_groups USING events
    WHERE event_to_state_groups.event_id = events.event_id 
    AND room_id = '$ROOMID'

I think it is much easyer and also deletes orphaned entries like this:

DELETE FROM event_to_state_groups WHERE event_id NOT IN (SELECT event_id FROM events)

am I right?

@richvdh what other tables have orphaned entries after using the old nuke script?

@rubo77
Copy link
Contributor

rubo77 commented Oct 13, 2018

A more secure way to clear event_to_state_groups will be these commands:

-- check how many rows in event_to_state_groups

SELECT count(*) from event_to_state_groups;

-- create temporary TABLE event_to_state_groups_to_delete with event_ids that are missing in events TABLE

BEGIN;
SET enable_seqscan=off;
SELECT s.event_id INTO event_to_state_groups_to_delete FROM event_to_state_groups AS s 
LEFT JOIN events
ON s.event_id = events.event_id
WHERE events.event_id IS NULL;
COMMIT;

-- check how many rows will be deleted

SELECT count(*) from event_to_state_groups_to_delete;

(this can take some minutes if you have millions of events already)

shut synapse down to delete the entries

(not sure if shutdown is needed)

-- delete obsolete entries

DELETE FROM event_to_state_groups WHERE event_id IN (SELECT event_id FROM event_to_state_groups_to_delete);

start it up again

-- delete temporary TABLE event_to_state_groups_to_delete;

DROP TABLE event_to_state_groups_to_delete;

Do I understand it right, that event_to_state_groups only connects events with state_group on the same serer?
so If there are event_ids in event_to_state_groups that are not in events, they can be deleted?
And the same with the state_groups table: if there are event_ids in state_groups that are not in events, they can be deleted?

If so, then we would have to do the same deletion script with state_groups too?

@karl007
Copy link

karl007 commented Feb 13, 2020

For everyone who search for a secure solution to delete a room (or something nearby), I create a php script as replacement for the nuke-room-from-db script, but use the API to kick all users and then let the garbage collector remove the empty room instead of deleting membership in the DB (and maybe miss something or screw up the DB): https://gist.github.com/karl007/521f6ab84a398ee27118ab89aae7a9dc

php riot_delete_room.php https://matrix.org "MDA...kYK" "#alias:domain.de"

The script only shows all members and the stop and ask if the members should kick. Then ask for a reason and a possible userId which should not kicked.

@richvdh
Copy link
Member Author

richvdh commented Feb 13, 2020

@rubo77
Copy link
Contributor

rubo77 commented Feb 16, 2020

The purge api seems to be only able to remove empty rooms.

The old nuke script was meant to repair unaccessible rooms, or rooms that contain errors. would the php script be able to remove those rooms too?

I would love to have a real new nuke-script (if the synapse api doesn't work any more for example to remove an old broken room with some foreign-key entries missing in my database that always sais, there is an unread message, but there isn't and where I cannot post or do anything inside any more)

@worldowner
Copy link

PHP script posted above won't delete private rooms if admin is not joined to them. What would be needed is an admin api that allows server admin to kick any user from any room regardless of membership. Then purge_room api could be used.

@rubo77
Copy link
Contributor

rubo77 commented Mar 29, 2020

/_synapse/admin/v1/purge_room can only purge rooms, that have no users in it, does this mean no users from your homeserver or no users at all?

It would be helpful to add an option to purge it also, if there are still users in it that didn't log in for some years

@worldowner
Copy link

purge_room will delete data if no local user (any user having account on homeserver that you call purge_api on) is a member of a room being purged.

It will delete data from your homeserver even if users of remote homeserver are still in this room. Data will obviously still persist on remote homeservers.

@rubo77
Copy link
Contributor

rubo77 commented Apr 5, 2020

So this will be a problem, if there is at least one user from your HS (that might not be active any more or even only logged in a few years ago and then forgot his password).

@matrix-org matrix-org locked as resolved and limited conversation to collaborators Apr 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants