After carefully reviewing our code I have found several ways that using SCCC-based config servers will not result in a totally consistent backup, due to no oplog and other crucial features we use to create consistency.
I do not want to create a false sense of confidence if a consistent backup cannot be guaranteed in this scenario, especially when the project is named "mongodb_consistent_backup".
I propose that we totally phase-out SCCC-based config server support, either immediately or in a future release after much warning to our users.
The two options I see are:
Require CSRS config servers so we can guarantee consistency, remove SCCC logic. A side effect of this would be simplified code and QA/testing.
Log a WARNING that we cannot guarantee consistency with SCCC-mode and set a phase-out date in the future. Update README to warn of this.
Removing this support means users will need to use 3.2 or higher with CSRS mode to use the tool, which I understand would be high-impact for many.
After carefully reviewing our code I have found several ways that using SCCC-based config servers will not result in a totally consistent backup, due to no oplog and other crucial features we use to create consistency.
I do not want to create a false sense of confidence if a consistent backup cannot be guaranteed in this scenario, especially when the project is named "mongodb_consistent_backup".
I propose that we totally phase-out SCCC-based config server support, either immediately or in a future release after much warning to our users.
The two options I see are:
Removing this support means users will need to use 3.2 or higher with CSRS mode to use the tool, which I understand would be high-impact for many.