I think the issue could be that this db has replication factor of 1. So it cannot accommodate even one machine “failure”.
You should bring back that line to make the cluster healthy. Then:
for controlled machine exclusions, you can use the exclude command from fdbcli. This will first copy the data away from the machine, before excluding it from cluster. Once it is done, you can remove the process line for it from the config.
to accommodate uncontrolled failures, like the one you simulated by removing the process line, make the replication factor to be 2+ from fdbcli, and then try the file based removal again. This time the cluster should still do okay.
Be careful that your coordinator process is not excluded. You can increase coordinator process using coordinator fdbcli command to increase resiliency of coordinator process exclusion/failures.
Guarav’s recommendations are good, and to avoid a potential pitfall here I’ll point out one other detail that may impact you if you try to use a single machine for double replication. If you try to do this with the configuration you had above, I believe it will fail because it requires multiple machines. To make this work, you would need to simulate having different machines by configuring the machine IDs on your processes. For example:
I actually changed the number of processes to see how fdb scales when increasing the number of processes.
So changing the configuration back to the original was not to stimulate failures, I just wanted to go back to defaults without reinstalling fdb.
With gauravs answer, I was able to remove one of the four processes, but for getting back to the initial config I had to reinstall the server.