Provide tooling to recover from a corrupted (non-recoverable) fdb cluster

[mpilman]

There are several ways we can corrupt a cluster without losing a majority of data:

• We could lose enough tlogs so that we can't recover without losing any storages
• We could corrupt the txnStateStore - which will probably result in a bad state that it is hard to recovery from.
• ..

In some of those cases, even fearless might not help (as the corruption might have been replicated). While restoring from a backup (or even better snapshot) would be possible, recovering from a snapshot will almost always result in some amount data loss. It could also be that that cluster didn't have any backups (hopefully all of our users are running backups - but you never know).

Anyways: there might be situations where a recovery with a small amount of data corruption and data loss is preferable. To do that I would like to have a tool that can read all files from a corrupted cluster and recover as much data as possible. The easiest version I can think of is the following:

• Look in a given directory for all KV-files.
• Read these files and scan the whole normal key-space
• Write these kv-pairs to another cluster

After this is done for all storages we would have (a probably corrupted) copy of the cluster that one could work with. Obviously, to make this useable, we would need to make this a bit more clever (as this would write every key up to three times for example - which would make the whole processes very slow).

[xumengpanda]

Will some allowed command in fdbcli cause corruption of a cluster? If yes, we may want to harden the fdbcli as well to avoid the misoperation.

(This question is more about how to reduce the possibility of corrupted cluster, instead of how to recovery.)

[mpilman]

Will some allowed command in fdbcli cause corruption of a cluster?

Of course - you can write transactions that directly modify stuff in the \xff keyspace 🥇

On a more serious note: I think that is a good point (although a bit off topic): we could have a simulation test that tries to run fdbcli commands that bring down the cluster. That way we probably could find many ways of actually doing this (and we could harden fdbcli).

[zbdba]

@mpilman Have you done this tool? We have some corrupted files for recovery.

[sfc-gh-mpilman]

Sorry for my late answer (usually for data loss events you should post to the forum where response times tend to be faster).

We did not write a proper version of the tools above. It would be great to have them and I would be happy to help in a consulting role, but sadly we currently don't have the resources to implement this. For an imminent event though it should be doable to do most of the above things manually.

[zbdba]

Okay, Thanks, We have recovered our corrupt data.

[weaversam8]

I'd like to emphasize the usefulness of such a tool - it's generally quite easy to get an FDB cluster in a bad state, and options to recover from that state are usually scarce. Either a tool as described (scan KVs and perform writes to a new cluster) or a better procedure to reunify a cluster one node at a time would help with this area.

[mavenraven]

@weaversam8 I'm currently exploring fdb, and would love to hear more detail please about "it's generally quite easy to get an FDB cluster in a bad state"!