Is fdb's recovery may drop committed transaction?

Development FoundationDB Core
1

When i read recovery internal : https://github.com/apple/foundationdb/blob/master/design/recovery-internals.md

in phase 3: https://github.com/apple/foundationdb/blob/master/design/recovery-internals.md#phase-3-recruiting

choose of recoveryVersion maybe below than durable version:

  • If all of them are alive during recovery, master will choose max(80, 90, 95) = 95 as the last epoch’s end version and min(100, 110, 120)=100 as the recovery version. Versions between 96 and 100 will be copied to new generation’s tLogs. Note some of them 101 to 120 are actually durable on one or two tLogs, but the master chooses to discard them. If a storage server has peeked versions in the range of [101, 120] , these versions are in memory of the storage server and will be rolled back (i.e., discarded).

if transaction committed in [101,120], it may be rollbacked in recovery ?

which induce a voliatle of Durablilty

2

if transaction committed in [101,120],

This IF won’t happen, because a txn won’t be committed until it’s durable on 3 TLogs (assuming we configure replication factor for tLogs as 3.)

3
  1. if transaction in [101,120] uncommitted, they also can be send to storage-server ?
    if so, when these transaction rollbacked finally, storage-server replay rollback TLog and do rollback ?
  2. replication use paxos or raft based consusens algorithm ?
4

Yes, [101, 120] may be sent to storage server already. The recovery transaction will reach all storage servers so that they can roll back these versions.

Replication is not using Paxos or raft. It’s basically proxy writes 3 replicas and wait for all 3 reply back.