Hi Jay, On Oct 28, 2004, at 10:40, Jay Daley wrote:
Johan
Johan wrote on 28/10/2004 09:02:10:
When it comes to zone updates we use a tcp/ip connection to the master server instead of altering the database directly. We don't need
to probe for db changes this way.
Well, that makes sense, but no one in their right mind is probing for changes since NOTIFY was defined many years ago.
As it happens we use probing not NOTIFY since it gives a greater level of control over the number of secondaries being updated at once (and the bandwidth) and the order in which they are updated. This does rely on strict calculations of the timings of changes and probes but that is fairly easy to do.
Certainly. But that only works if you relax the goal of more or less instant propagation of changes (to the slaves). I.e. that way you compromise synchronicity (is there such a word?) between slaves for the to you more important goal of managing your data streams. In your case the size of the data is non-trivial, so I understand the reasoning. Johan PS. I choose the word synchronicity rather than coherence, because as long as each slave publish exactly the same data for the same SOA serial they are technically coherent (to the version of the data they *have*) although they may be temporarily out of sync (with slaves having acquiered more recent data).