-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
kvdb: refactor as preparation for DB migration command in lndinit #5561
kvdb: refactor as preparation for DB migration command in lndinit #5561
Conversation
5773d84
to
7702c90
Compare
7702c90
to
e0850d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!!! ⚡ Just a quick glance, will do a more thorough review later!
cmd/lndinit/cmd_migrate_db.go
Outdated
return nil | ||
} | ||
|
||
err := dest.Put(k, v) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're missing the sequence migration in this case.
cmd/lndinit/cmd_migrate_db.go
Outdated
ctx, cancel := context.WithTimeout(ctx, etcdTimeout) | ||
defer cancel() | ||
|
||
_, err := cli.Put(ctx, key, value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
cmd/lndinit/cmd_migrate_db.go
Outdated
) | ||
}) | ||
if err != nil { | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ✨
channeldb/meta.go
Outdated
} | ||
|
||
key := markerBucket.Get(markerKey) | ||
if len(key) == 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice set of unit tests! linter complaints, otherwise LGTM💡
|
||
// Only adding the marker bucket should not be enough to be counted as | ||
// a marker, we explicitly also want the value to be set. | ||
err = db.Update(func(tx walletdb.ReadWriteTx) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
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
lndinit
to access the required library code.