Add lighthouse db purge dht subcommand
#2824
Comments
|
I think we should be careful about adding any more pseudo-databases due to the trouble we've had in the past with atomicity and crash safety. I think a separate Lighthouse command to delete the DHT could be good, like Alternatively if you want a separate file in the network dir you could use a separate DB, either LevelDB or SQLite. That would outsource the file I/O concerns to the database |
|
I was suggesting writing to a file since it's not a big deal even if it gets corrupted; we can start from a fresh dht with just the bootnodes and get a good peer count pretty fast. However, I like your |
|
Yeah I've been thinking of adding a db sub-command for a while. We could have |
|
There's some WIP code here that we could adapt: #2685 |
bors bot
pushed a commit
that referenced
this issue
Apr 1, 2022
## Proposed Changes Add a `lighthouse db` command with three initial subcommands: - `lighthouse db version`: print the database schema version. - `lighthouse db migrate --to N`: manually upgrade (or downgrade!) the database to a different version. - `lighthouse db inspect --column C`: log the key and size in bytes of every value in a given `DBColumn`. This PR lays the groundwork for other changes, namely: - Mark's fast-deposit sync (#2915), for which I think we should implement a database downgrade (from v9 to v8). - My `tree-states` work, which already implements a downgrade (v10 to v8). - Standalone purge commands like `lighthouse db purge-dht` per #2824. ## Additional Info I updated the `strum` crate to 0.24.0, which necessitated some changes in the network code to remove calls to deprecated methods. Thanks to @winksaville for the motivation, and implementation work that I used as a source of inspiration (#2685).
bors bot
pushed a commit
that referenced
this issue
Apr 1, 2022
## Proposed Changes Add a `lighthouse db` command with three initial subcommands: - `lighthouse db version`: print the database schema version. - `lighthouse db migrate --to N`: manually upgrade (or downgrade!) the database to a different version. - `lighthouse db inspect --column C`: log the key and size in bytes of every value in a given `DBColumn`. This PR lays the groundwork for other changes, namely: - Mark's fast-deposit sync (#2915), for which I think we should implement a database downgrade (from v9 to v8). - My `tree-states` work, which already implements a downgrade (v10 to v8). - Standalone purge commands like `lighthouse db purge-dht` per #2824. ## Additional Info I updated the `strum` crate to 0.24.0, which necessitated some changes in the network code to remove calls to deprecated methods. Thanks to @winksaville for the motivation, and implementation work that I used as a source of inspiration (#2685).
paulhauner
pushed a commit
to paulhauner/lighthouse
that referenced
this issue
Apr 4, 2022
## Proposed Changes Add a `lighthouse db` command with three initial subcommands: - `lighthouse db version`: print the database schema version. - `lighthouse db migrate --to N`: manually upgrade (or downgrade!) the database to a different version. - `lighthouse db inspect --column C`: log the key and size in bytes of every value in a given `DBColumn`. This PR lays the groundwork for other changes, namely: - Mark's fast-deposit sync (sigp#2915), for which I think we should implement a database downgrade (from v9 to v8). - My `tree-states` work, which already implements a downgrade (v10 to v8). - Standalone purge commands like `lighthouse db purge-dht` per sigp#2824. ## Additional Info I updated the `strum` crate to 0.24.0, which necessitated some changes in the network code to remove calls to deprecated methods. Thanks to @winksaville for the motivation, and implementation work that I used as a source of inspiration (sigp#2685).
paulhauner
pushed a commit
to paulhauner/lighthouse
that referenced
this issue
May 6, 2022
## Proposed Changes Add a `lighthouse db` command with three initial subcommands: - `lighthouse db version`: print the database schema version. - `lighthouse db migrate --to N`: manually upgrade (or downgrade!) the database to a different version. - `lighthouse db inspect --column C`: log the key and size in bytes of every value in a given `DBColumn`. This PR lays the groundwork for other changes, namely: - Mark's fast-deposit sync (sigp#2915), for which I think we should implement a database downgrade (from v9 to v8). - My `tree-states` work, which already implements a downgrade (v10 to v8). - Standalone purge commands like `lighthouse db purge-dht` per sigp#2824. ## Additional Info I updated the `strum` crate to 0.24.0, which necessitated some changes in the network code to remove calls to deprecated methods. Thanks to @winksaville for the motivation, and implementation work that I used as a source of inspiration (sigp#2685).
michaelsproul
changed the title
lighthouse db purge dht subcommand
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Currently, we persist the lighthouse dht on exit and load from the db on startup. The persisted dht is stored in the hot db under the
DhtEnrscolumn.This makes it inconvenient to start from a fresh dht as we would have to delete the specific column from the hot db on startup. Also it seems a bit weird to persist the networking dht in the beacon chain hot db as you don't need the dht to load the chain.
IMO, it would make more sense to store it in a separate file under the
beacon/networkdirectory. This would allow us to simply delete thedhtfile if we want to start from a fresh dht. Deleting the entirebeacon/networkdirectory would also give us a fresh networking node where we get a new network identity and just the bootnodes from the provided config (equivalent to--purge-dbfor the beacon chain).The text was updated successfully, but these errors were encountered: