Issues that came up when implementing
Thank you for this! I have two replicas in other regions running 🚀!
I hit a few issues which I may be able to make a PR for in the coming days. They aren't major but did take a bit of digging:
Briefly:
- Being new to replication, I didn't realize each subscription needs a unique name
- I had the
pg_graphqlextension enabled on my primary. Executing the schema on the read replicas didn't fail, but the resultant structure didn't actually match.graph._typewas the first error. I disabledgraphqlwhich brought that part in line. - New projects have
pgsodiumenabled by default it seams, making the schema's different. My primary was from several months back. - Enabling
pgsodiumon the primary does add it to the schema dump, but it fails as thepgsodium.keyrelation wasn't found. I'll have to check my notes for the error. - Disabling
pgsodiummanually on all three, going through the steps, then re-enabling them afterwards worked. Doing a structure diff showed they were all identical. Extensions were all a go then. - Data still didn't update so I put in all the log levels just in case. The logging Errors template doesn't include
Warningwhich is needed to see the worker error.
Once I updated the max workers and restarted it immediately backfilled and changes were being propagated.
Thanks again!
Thanks for the great, detailed feedback. Our basic migration document has recently changed so we may want to update this repo to help solve some of the stuff you ran into. See: https://supabase.com/docs/guides/platform/migrating-and-upgrading-projects
@burggraf it seems that the migration document linked there would result in some downtime, but the approach in this repo would still be better for less downtime, right?
I'm trying to upgrade our pg version. My plan was to use the instructions here to create a replica and then once it was synced, change my app to use the credentials for the new replica. Then delete the old database. Would that still work?