Hi there. I read fdb paper in SIGMOD’21 these days. And I found it mentioned that at the end of chapter 2.4:
When Sequencer accepts new transactions, the first is a specialrecovery transaction that informs StorageServers the RV sothat they can roll back any data larger than RV. The current FDBstorage engine consists of an unversioned SQLite  B-tree andin-memory multi-versioned redo log data. Only mutations leavingthe MVCC window (i.e., committed data) are written to SQLite. Therollback is simply discarding in-memory multi-versioned data inStorageServers. Then StorageServers pull any data larger thanversion 𝑃𝐸𝑉 from new LogServers.
The description here confuses me. So this MVCC window is the same window in Resovlers? Is this a transaction that has been in Resolvers or StorageServers for more than 5s are written to SQLite? If the latter, how does this mechanism ensure that the client does not read transactions that are actually uncommitted? (For example, a LogServer downed, and the entire transaction system needs to recovery. If the recovery time is more than 5s, the StorageServer may set some umcommitted data to committed state, and clients will read wrong data before the system rollback these data.)
The paper doesn’t seem to describe in detail how the StorageServer maintains these MVCC, so that led me to these questions. So is this 5s window only related to Resolvers, or do StorageServers need to maintain their own 5s window as well?
Furthermore, when should Proxy reply client that the transaction has been committed? It mentions in the chapter 2.4.1:
A transaction is considered committed after all designated LogServers have replied to the Proxy, which reports the committed version to the Sequencer (to ensure that later transactions’ read versions are after this commit) and then replies to the client.
What’s the meaning of ‘all designated LogServers’ here? It means all LogServers in the Data Plane, or all LogServers which meet high availability requirements (i.e. k LogServers in the fdb, k is the replication degree.) I think if it’s the latter, there will be problems in recovery.
At last, if a Resolver returns abort to the Proxy, should this transaction log be sent to LogServers for persistence? This implementation detail does not seem to be mentioned in the paper. I think if it doesn’t do that, the next transaction may take a previous LSN which is its commit version, it may cause some matters. In short, should the log of an abort transaction be durable in LogServers?
Looking forward to your response, thanks!