As I understand it, the FDB cluster is ‘aware’ of transactions that are in-flight on a client currently.
I’m also aware that fdbdr switch temporarily locks both clusters while it synchronises the last bit of data between them, then swaps around the DR relationship.
We have some processes which are triggered by updates to FDB keys, and then make external/‘side effecting’ calls as a result of that. Where relevant we are using idempotency keys and such, and of course there can always be non-DR reasons why a tx might fail to commit so we have to be able to deal with those manually if necessary.
I am just trying to understand the likelihood of seeing issues with this during a failover test. Will the DB be locked mid-transaction, so that it’s likely any in-flight transactions will be lost, or is part of the ‘few seconds wait’ that fdbdr switch has while it’s reconciling the last of the data between the two in part to allow any in-flight txes to either exceed their 5s limit and time out or commit their data before the final switch sync occurs?