Hallvard Breien Furuseth wrote:
On 29. jan. 2015 04:12, Howard Chu wrote:
I'm considering adding an option to the consumer to write its entries with dbnosync during the refresh phase. The rationale being, there's nothing to lose anyway if the refresh is interrupted. I.e., the consumer can't update its contextCSN until the very end of the refresh, so any partial refresh that gets interrupted is wasted effort - the consumer will always have to start over from the beginning on its next refresh attempt.
dbnosync loses consistency after a system crash, and it loses the knowledge that the DB may be inconsistent. At least with back-mdb. The safe thing to do after such a crash is to throw away the DB and fetch the entire thing from the provider. Which I gather would need to happen automatically with such an option.
From my purely operatinal standpoint:
The consumer does not have valid contextCSN before being fully synced. This must be ensured. Everyting else can be handled separately. In a serious deployment the monitoring will have the red light on for this replica, decent health-check in load-balancers will disable using this replica.
=> don't over-engineer too many things to happen automagically, especially if you're not 100% sure that this auto-magic is rock-solid on every supported OS platform and in every exotic operational situation.
Ciao, Michael.