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.