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

Reply via email to