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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature