raft: auto-commit transactions of the old leader
According to Raft, when a new leader is elected, it should finish transactions of the old leader. In Raft this is done via adding a new transaction originated from the new leader. In case of Tarantool this can be done without a new transaction due to WAL format specifics, and the function doing it is called box_clear_synchro_queue(). Before the patch, when a node was elected as a leader, it didn't finish the pending transactions. The queue clearance was expected to be done by a user. There was no any issue with that, just technical debt. The patch fixes it. Now when a node becomes a leader, it finishes synchronous transactions of the old leader. This is done a bit differently than in the public box.ctl.clear_synchro_queue(). The public box.ctl.clear_synchro_queue() tries to wait for CONFIRM messages, which may be late. For replication_synchro_timeout * 2 time. But when a new leader is elected, the leader will ignore all rows from all the other nodes, as it thinks it is the only source of truth. Therefore it makes no sense to wait for CONFIRMs here, and the waiting is omitted. Closes #5339
Showing
- src/box/box.cc 34 additions, 8 deletionssrc/box/box.cc
- src/box/box.h 2 additions, 1 deletionsrc/box/box.h
- src/box/lua/ctl.c 1 addition, 1 deletionsrc/box/lua/ctl.c
- test/replication/election_qsync.result 154 additions, 0 deletionstest/replication/election_qsync.result
- test/replication/election_qsync.test.lua 77 additions, 0 deletionstest/replication/election_qsync.test.lua
- test/replication/election_qsync_stress.result 0 additions, 1 deletiontest/replication/election_qsync_stress.result
- test/replication/election_qsync_stress.test.lua 0 additions, 1 deletiontest/replication/election_qsync_stress.test.lua
Loading
Please register or sign in to comment