Migrating for Chang HF: ERROR: cannot alter type of a column used by a view or rule #1822
Labels
bug
Something isn't working
Comments
|
Update: The other APIs/components of the stack was affecting dbsync migrations. A cleanup script did the trick and now it is purging ledger state files and seems starting as expected. PostgresDb and node db data is kept intact. Closing the issue!. |
|
I'm reopening this issue as these new SQL operations after boot are getting triggered when restarting services and are now proven to be incompatible with our pre-conway stack. Previously, views applied to the indexed tables were not breaking db-sync boot process Is it possible for you to run these new migrations/actions without halting db-sync if data and views are already there? Logs on boot: |
|
This is curious: Did you change any config before restarting? |
|
Hi @sgillespie ! Our backend consists on Cardano GraphQL, Koios and Dandelion-PostGREST. As Cardano GraphQL is the most complex dependency, we always start upgrading by following their latest setup. In this case config files came from https://github.com/cardano-foundation/cardano-graphql/tree/8.2.1 tag. What config you think may be involved? Update (clarification): To manage to put all services up now this is the procedure I have to do manually:
on system restarts I am forced now to manually follow this procedure again to keep systems online, what is not ideal. Before this update, everything was working smoothly. |
|
Sorry, I'm just referring to the db-sync configuration (presumably |
|
well yes @sgillespie , in that case i can confirm some files, not that exactly has changed for Chang. for example: config/network/mainnet/cardano-db-sync/config.json |
|
During these hours the posgresDB container volume grew up to 1.2TB and I had to wipe the volume as emergency measure to gain control back of the OS. As far as I could find out, podman logs where not the reason, but something else writing on the volume. These were last postgresDB logs (maybe irrelevant) and these are the latest dbsync logs (last db write attempts): |
|
Some API-created views of These views has been working perfectly in the past prior to this new version. Can you guys relax a bit those initial operations to avoid failing at least if cannot be executed? We are running out of time so I'm crippling some wallet features for now in order to survive Chang for our users. Hope you can help. |
|
Ideally , any secondary layer changes should not be made on same schema as db-sync itself. The dbsync mainnet database size (including tx_cbor flag recently added, which amounts to ~180GB ) is still around 600GB (if not using tx_cbor flag, that'd be ~410-420GB). I would strongly oppose requests to add changes to dbsync for something introduced externally, they should be managed in their own schema and sized accordingly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OS
Your OS:
Versions
The
db-syncversion (egcardano-db-sync --version):Docker image: ghcr.io/intersectmbo/cardano-db-sync:13.4.0.1PostgreSQL version:
16.1-bullseyeBuild/Install Method
The method you use to build or install
cardano-db-sync:docker-compose (podman)Run method
The method you used to run
cardano-db-sync(eg Nix/Docker/systemd/none):docker-compose (podman)Additional context
Add any other context about the problem here.
Problem Report
Please do not include screenshots or images, but instead cut and paste any relevant log messages
or errors.
When updating node and APIs versions for Chang hard fork I find this issue that crashes db-sync.
This happens whether I remove the ledger state files or keep the old ones (even dropping dbsync volume). This while keeping postgresDB and cardano-node-ogmios database volumes intact to speedup sync and migration.
$ cat /tmp/migrate-2024-08-22T00:40:32.347837119Z.log
The text was updated successfully, but these errors were encountered: