We should probably change the consumer such that when multiple consumers are configured on a context, only one of them can be active at a time. In particular, in refresh phase, you'll get multiple redundant copies of the refresh data. All providers should be equivalent, so whichever one we connect to first should be used and any others should be left idle.
Or, each session should be established completely sequentially - do a complete refresh from provider #1, then do the same for provider #2, etc... In a quiescent setup, the refreshes after provider #1 will be no-ops because the consumer is already up to date. In a busy setup, each refresh will still have work to do but it will be a smaller volume after provider #1's refresh completes.
Simplest would be to just establish the first connection and ignore other providers unless the first connection breaks. Unfortunately this wouldn't be reliable in MMR - you could have two nodes pointed at each other, ignoring any other nodes in the configuration.
On Tue, May 12, 2015 at 07:27:22PM +0100, Howard Chu wrote:
Or, each session should be established completely sequentially - do a complete refresh from provider #1, then do the same for provider #2, etc... In a quiescent setup, the refreshes after provider #1 will be no-ops because the consumer is already up to date. In a busy setup, each refresh will still have work to do but it will be a smaller volume after provider #1's refresh completes.
Presumably the earlier connections would have entered persist state by then, so some of the changes could already have arrived.
Simplest would be to just establish the first connection and ignore other providers unless the first connection breaks. Unfortunately this wouldn't be reliable in MMR - you could have two nodes pointed at each other, ignoring any other nodes in the configuration.
That suggests that the consumer should attempt refresh from every supplier whenever it can establish a new connection, but that a preference order should be applied so that it does not try to refresh from a distant/slow provider first.
Andrew
On Tue, May 12, 2015 at 07:27:22PM +0100, Howard Chu wrote:
We should probably change the consumer such that when multiple consumers are configured on a context, only one of them can be active at a time. In particular, in refresh phase, you'll get multiple redundant copies of the refresh data. All providers should be equivalent, so whichever one we connect to first should be used and any others should be left idle.
Or, each session should be established completely sequentially - do a complete refresh from provider #1, then do the same for provider #2, etc... In a quiescent setup, the refreshes after provider #1 will be no-ops because the consumer is already up to date. In a busy setup, each refresh will still have work to do but it will be a smaller volume after provider #1's refresh completes.
Hi, that should work just fine if you say "only one present/delete phase can be active at a time*", once you receive the Sync Info Message, you can start connecting to another provider. Or you might decide to stop at that point, based on whether the DB is in MirrorMode. Stopping could still break some exotic "MMR" topologies, though, not that I know of anyone running them.
Also, if the olcSyncRepl directives are ordered correctly, the most expensive phase would usually be served from a nearby provider.
* per suffix if you want to talk to one provider only
Cheers, Ondra
-
Andrew Findlay -
Howard Chu -
ondra＠mistotebe.net