introduce --replicaof flag
#1583
Conversation
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <41526934+talbii@users.noreply.github.com>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
…roduce `ReplicaOfFlag` Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
…until `REPLICAOF NO ONE` is recieved Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <41526934+talbii@users.noreply.github.com>
src/server/server_family.cc
Outdated
| }; | ||
| transaction->Execute(std::move(cb), true); | ||
| if (should_flush_db == ShouldFlushDb::kFlush) | ||
| FlushEntireDb(cntx->transaction); |
There was a problem hiding this comment.
Wouldn't this be a problem, in that after this function finishes the transaction will be concluded afterwards? Or is it ok to Schedule() an already concluded transaction?
There was a problem hiding this comment.
that I am not too sure about, but I'm not sure I understand your concern? The logic of FlushEntireDb (or FLUSHDB or Drakarys..) schedules the transaction first and then executes it, which is fine.
Are you worried that replication continues past the already-executed transaction?
Maybe @romange could chime in, I saw that he originally wrote this code 🙂
There was a problem hiding this comment.
I'm worried that transactions can't be used more than once, in which case maybe something unintended can happen after we flush the DB, when we try to use the tx again
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
Signed-off-by: talbii <ido@dragonflydb.io>
src/server/replica.cc
Outdated
| * an instance with '--replicaof' and then \b immediately | ||
| * sending a command. | ||
| * | ||
| * In that instance, we have to run f() on the current fiber. |
There was a problem hiding this comment.
But what's the downside of running in current fiber? Why not always do it as such? And why not run it just via f() instead of awaiting for our own thread?
There was a problem hiding this comment.
that I am not entirely sure about. Presumably this was done in order to not block the current fiber, the same fiber that runs MainReplicationFb.
About why I run f() using AwaitBrief, I was not sure that was the same outcome. I'll change it, thanks!
Signed-off-by: talbii <ido@dragonflydb.io>
Closes #1381.