kvdb: refactor as preparation for DB migration command in lndinit#5561
Conversation
5773d84 to
7702c90
Compare
7702c90 to
e0850d0
Compare
bhandras
left a comment
There was a problem hiding this comment.
Awesome!!! ⚡ Just a quick glance, will do a more thorough review later!
| return nil | ||
| } | ||
|
|
||
| err := dest.Put(k, v) |
There was a problem hiding this comment.
I think we're missing the sequence migration in this case.
| ctx, cancel := context.WithTimeout(ctx, etcdTimeout) | ||
| defer cancel() | ||
|
|
||
| _, err := cli.Put(ctx, key, value) |
There was a problem hiding this comment.
One quick low hanging speedup is to gather key/values to a buffer then when the buffer hits say 100-1000 items then flush it to etcd in one txn. It's doable since the individual keys don't depend on each other.
| ) | ||
| }) | ||
| if err != nil { | ||
| return err |
There was a problem hiding this comment.
Not sure but perhaps we could delete all keys at this point? Just to avoid leaving any junk in the DB.
|
!lightninglabs-deploy mute 2022-Feb-01 |
|
@guggero, remember to re-request review from reviewers when ready |
|
!lightninglabs-deploy mute |
|
Is this safe to use for an existing bolt lnd installation? |
No, this hasn't been tested sufficiently and isn't recommended to be used (which is also the main reason for this not to be merged yet). |
|
Hey there, I've compiled this code and tried to test it out on one of our regtest nodes. However I've failed to do a migration due to the fact that the current channeldb version is already 27, while this version of I'd love to test out the migration (on regtest) if these dependencies could be brought up-to-date. |
e0850d0 to
645239a
Compare
|
Done, @kiwiidb see lightninglabs/lndinit#21. Please don't use this for production/mainnet data! |
645239a to
bd95d5c
Compare
|
This is now just basic refactoring code, I think we can review and merge, @bhandras. |
There was a problem hiding this comment.
I think we need to check key against nil here if we want to validate the markerKey's existence. Checking len(key) == 0 seems to have a different meaning as it's checking what's stored, not whether it's stored. Also nit but we may rename key to value or data here as it's the value we get from the bucket...
There was a problem hiding this comment.
You are correct, there is a difference between an empty slice and nil. But in our case it doesn't matter which it is, it just means the marker wasn't added correctly. So both cases are equivalent in this case. Added a comment to clarify and also renamed the variable.
bd95d5c to
dd03017
Compare
dd03017 to
b420e6d
Compare
b420e6d to
c1051d2
Compare
yyforyongyu
left a comment
There was a problem hiding this comment.
Nice set of unit tests! linter complaints, otherwise LGTM💡
In order for us to be able to re-use the code for initializing an etcd client connection, we extract and export the NewEtcdClient function.
We'll need to know whether a database was migrated to the latest version in our upcoming data migration tool. To be able to determine the current version of a DB and the total number of migrations in existence, we need to export some of the functions in channeldb. We also add some helper functions for adding tombstone and other markers to a database.
To avoid running a channel DB that was successfully migrated to another system by accident, we check if there is a tombstone marker before we open the DB for use.
For the data migration tool we need to know what database namespaces there are so we can loop over them.
c1051d2 to
4e42ef0
Compare
EDIT: The main migration tool has moved to lightninglabs/lndinit#21 (still not ready for production/mainnet use!)
The code in this PR is now purely a refactor to allow
lndinitto access the required library code.