-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document historical reindexing process for abci events #4566
Comments
Syncing a new cometbft instance will solve the event emission problem. |
Due to an oversight in the volume-mount path, out postgres databases for indexing ABCI events via CometBFT's psql indexer setup were not persisting across node restarts. This was due to the fact that the upstream `postgres` container image declares its own VOLUME at `/var/lib/postgresql/data`, visible here: ❯ podman inspect docker.io/postgres:16-bookworm | jq '.[0].Config.Volumes' { "/var/lib/postgresql/data": {} } which clobbered our manual mount at `/var/lib/postgresql`, a level up. We must override the volume mountpoint in order for the PVC to take precedence over the anonymous volume. Done by adding the fullpath to that exact mount, and then overriding PGDATA to use a subdir therein. Also pins a stable version of the container image tag, so we don't get surprised by postgres jumps. Refs #4526. Will make sure this applies cleanly automatically on preview post-merge, then will update the deployments for currently-running networks. Does not handle historical reingestion; that's tracked separately in #4566.
Due to an oversight in the volume-mount path, out postgres databases for indexing ABCI events via CometBFT's psql indexer setup were not persisting across node restarts. This was due to the fact that the upstream `postgres` container image declares its own VOLUME at `/var/lib/postgresql/data`, visible here: ❯ podman inspect docker.io/postgres:16-bookworm | jq '.[0].Config.Volumes' { "/var/lib/postgresql/data": {} } which clobbered our manual mount at `/var/lib/postgresql`, a level up. We must override the volume mountpoint in order for the PVC to take precedence over the anonymous volume. Done by adding the fullpath to that exact mount, and then overriding PGDATA to use a subdir therein. Also pins a stable version of the container image tag, so we don't get surprised by postgres jumps. Refs #4526. Will make sure this applies cleanly automatically on preview post-merge, then will update the deployments for currently-running networks. Does not handle historical reingestion; that's tracked separately in #4566.
Progress! Dumping some notes here so I can pick this back up. The process so far is a bit clunky, but it's definitely tractable. We want to reindex events on the
Now you should see blocks syncing from node1 -> node2, and more importantly, node2 -> postgres. Once node2 catches up the node1's halt height, the ABCI event db will have blocks 1 -> halt height. Then it's time to shift versions, redeploy backups, and sync again. That piecemeal process, unscripted, should get us full recovery of historical events. Once we have a db, we can shove that behind the relevant frontends. |
Update on progress: I've successfully reindexed blocks 0 through 219220 on penumbra-testnet-deimos-8, using pd v0.75.1, using the process described above. Next up, we need to reindex events from height 220220 to 326700, which matches pd versions 0.76.x to 0.77.x. To do so, we must perform some version gymnastics, related to the overhaul of halting logic in #4373: specifically, we want to run v0.76.0, but restoring from a backup on that state will not let us resume the chain. So we'll briefly use So the steps for reindexing 220220 to 326700 on
You should now see blocks streaming from node1 to node2, and ABCI events for each block added to the postgresql db. Wait for the next chain halt, at height 326700, and then it's time to update versions once again. |
Nice! |
Collects some information from the cuiloa README [0], as well as some generalized instructions captured in #4566, particularly the use of `--ready-to-start` from #4499. Refs #4494, closes #4566. [0] https://github.com/penumbra-zone/cuiloa/blob/dc4133f7b36706cdf5a3ee6b4e0fb2c09e5a8bb8/README.md
Collects some information from the cuiloa README [0], as well as some generalized instructions captured in #4566, particularly the use of `--ready-to-start` from #4499. Refs #4494, closes #4566. [0] https://github.com/penumbra-zone/cuiloa/blob/dc4133f7b36706cdf5a3ee6b4e0fb2c09e5a8bb8/README.md
We need figure out the process for creating an ABCI event database from scratch. The process should look something like:
Let's do it manually for now, working from private backups. When I last tried this, getting cometbft to "replay" blocks to pd over ABCI was fairly simple: unfortunately, that replay process did not result in ABCI events being emitted to a newly created sidecar indexing db. Why is that? Is there some other process we should use to handle this use case?
Closely related to #4525 & #4526.
The text was updated successfully, but these errors were encountered: