replication: add strict ordering for appliers operating in a full mesh
In some cases when an applier processing yielded, other applier might start some conflicting operation and break replication and database consistency. Now applier locks a per-server-id latch before processing a transaction. This guarantees that there is only one applier request for each server in progress at each given moment. The problem was very rare until full mesh topologies in vinyl became a commonplace. Fixes gh-3339
Showing
- src/box/applier.cc 24 additions, 1 deletionsrc/box/applier.cc
- src/box/replication.cc 12 additions, 0 deletionssrc/box/replication.cc
- src/box/replication.h 18 additions, 0 deletionssrc/box/replication.h
- test/replication/ddl.lua 33 additions, 0 deletionstest/replication/ddl.lua
- test/replication/ddl.result 36 additions, 0 deletionstest/replication/ddl.result
- test/replication/ddl.test.lua 18 additions, 0 deletionstest/replication/ddl.test.lua
- test/replication/ddl1.lua 1 addition, 0 deletionstest/replication/ddl1.lua
- test/replication/ddl2.lua 1 addition, 0 deletionstest/replication/ddl2.lua
- test/replication/ddl3.lua 1 addition, 0 deletionstest/replication/ddl3.lua
- test/replication/ddl4.lua 1 addition, 0 deletionstest/replication/ddl4.lua
Loading
Please register or sign in to comment