-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Background updates failed after upgrading from Synapse 1.25.0 #15677
Comments
Maybe some more context after digging some more into this. I checked the following tables:
After digging some more into this I noticed that the constraints which are preventing the column from being deleted are added in schema version In a cloned setup I tried deleting the constraints from
After starting synapse again the migration continues and finished without any more errors, but it took over an hour. At the end I tried adding the constraints again, which also worked:
So I have a few questions for this: Is this a valid solution and is it save to do the migrations like that or did I made the whole setup much worse and should do something else to fix it? |
Hello - it sounds like you are requesting support rather than reporting a bug. I am going to direct you to #synapse:matrix.org where you can ask questions and get support. |
I disagree -- this very much sounds like we have a bug somewhere in our background updates and we should investigate further: it sounds like there might be a dependency. missing between background updates? |
Got it I will take a deeper look. |
AFAICT, this looks like an interaction between the application of schema delta files and a background update. As the reporter noted, the schema delta file synapse/synapse/storage/databases/main/events_bg_updates.py Lines 45 to 46 in 6fc3deb
Meanwhile schema delta synapse/synapse/storage/schema/main/delta/74/03_membership_tables_event_stream_ordering.sql.postgres Lines 22 to 29 in 6fc3deb
Schema deltas are applied when we are preparing the database, so my best guess is that since the second delta in question was not a background update it was applied immediately, adding the constraints referencing the I wonder if this could be fixed by changing the delta in As for the question:
Dropping the offending constraints, running the rest of the migration and then re-adding the constraints back in doesn't sound unreasonable to me, but I will ask @clokep to confirm that this is a safe action as we generally do not advise admins operate on the database directly. |
It looks legit to me. As for every manual database action PLEASE PLEASE PLEASE backup your DB before trying that. Thanks ! |
This looks like a proper solution, but I am unsure that we have an easy way to express dependency between bg update jobs. I had a quick look but couldn't find an example, but I didn't review all of them there are a bunch. A way to do it would be to busy wait for the bg update to be marked complete in the DB table for bg updates. |
It looks like when inserting a background job in to the DB you can specify another background job that must finish before the one you are inserting can be run, like so: synapse/synapse/storage/schema/main/delta/54/stats.sql Lines 71 to 76 in e0f2429
This was what I was thinking of. |
Description
I upgraded my old synapse server (v1.25.0) a few days ago to the latest version of synapse (1.84.0). Today I discovered that some background migrations failed (see log). If I understand this correctly some database schema migrations have failed. Is there any chance I can fix this errors without destroying the whole server?
Steps to reproduce
Homeserver
private
Synapse Version
1.84.0
Installation Method
Docker (matrixdotorg/synapse)
Database
PostgreSQL, no seperate servers
Workers
Single process
Platform
Debian VPS
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response
The text was updated successfully, but these errors were encountered: