Since in https://github.com/XiaoMi/rdsn/pull/1087 we've supported to set env for the replication factor in case there are duplicate requests trying to update the same table, there is still a problem that the request for updating replication factor may fail once meta server crashes. It's possible that there are partial steps finished while others are uncompleted.
Therefore, After meta server has got primary lock, it will initialize, during which recovering replication factor should be relaunched. Any table whose env of updating replication factor is not removed (once updating replication factor is complete, the env will be eliminated) will be the candidate that needs to recover as long as it's available. All tables should have been restored before the initialization is finished.
This is a subtask of https://github.com/apache/incubator-pegasus/issues/865.
Since in https://github.com/XiaoMi/rdsn/pull/1087 we've supported to set env for the replication factor in case there are duplicate requests trying to update the same table, there is still a problem that the request for updating replication factor may fail once meta server crashes. It's possible that there are partial steps finished while others are uncompleted.
Therefore, After meta server has got primary lock, it will initialize, during which recovering replication factor should be relaunched. Any table whose env of updating replication factor is not removed (once updating replication factor is complete, the env will be eliminated) will be the candidate that needs to recover as long as it's available. All tables should have been restored before the initialization is finished.