> ROA <-- MA <--> MB --> ROB
> Where RO is a readonly, M is a master. Arrows indicate data flow
> Updates to the DS are done through MA or MB.
> Should the advice of enabling on only a single host still be held true?
from my understanding, the plugin will generate internal operations which will be
replicated to all the other suppliers and consumers keeping the coherency (integrity) of
entries in all the nodes of the topology.
> What are the potential issues of enabling this on multiple hosts? In the
I haven't tested but perhaps we could eventually generate some replication conflicts.
I imagine the same operations taking place simultaneously (because of same update
interval) in several masters and being replicated.
Also some performance degradation.
Wouldn't the internal operation be done in the same transaction?
*does some internal ops*
Send replica update for mod.
Is that not how it works? Are the internal operations non transactional?
> future what would need to change in the plugin to support enabling on
> multiple hosts if not already possible?
Do you mean with same configuration in all of the masters ? I don't think it's
worth because the operations will be replicated.
Let's think of a normal mod operation. It would be useless to do the same modify
operation in all the masters. It will fail in the second one if the operation has already
been replicated. Or it will generate a conflict if done simultaneously.
In the same way, the internal MOD operations issued by the plugin should be done in only
Well really, you would think that one master would do the change, then
it would replicate a correct set of attributes to the second that could
"trust" that the incoming replication is already correct.
Anyway, I think I'd need to look at the internals of the plugin at this
point to work out for sure what's going on.