-
Notifications
You must be signed in to change notification settings - Fork 600
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
add flushdb option for repl-diskless-load #909
base: unstable
Are you sure you want to change the base?
Conversation
789a3fd
to
7eccdd3
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## unstable #909 +/- ##
============================================
+ Coverage 70.59% 70.61% +0.01%
============================================
Files 114 114
Lines 61670 61671 +1
============================================
+ Hits 43538 43550 +12
+ Misses 18132 18121 -11
|
Signed-off-by: kronwerk <> Signed-off-by: kronwerk <[email protected]>
Signed-off-by: kronwerk <[email protected]>
Signed-off-by: kronwerk <[email protected]>
I think this is a reasonable policy to add and it doesn't increase the complexity. @valkey-io/core-team |
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 am ok with this, i mention this option in #653 (comment)
It seems OK, but maybe risky that some users lose data by mistake.
What is the use case? Why don't they want to explicitly call FLUSHALL before starting replication? If we require them to do it explicitly, it is less likely that some user will lose data by mistake. |
once upon a time it was an initial way to make diskless replication - without any checks.
but it was frown away because it's dangerous (and it is still dangerous, of course).
but in some situations for some users, that think they know what they're doing, it's ok.
let's pls allow this for those. thx