> > > > > > ROA <-- MA <--> MB --> ROB > > > > Where RO is a readonly, M is a master. Arrows indicate data flow > > direction. > > > > Updates to the DS are done through MA or MB. > > > > Should the advice of enabling on only a single host still be held true? > > Hi William, > > 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? begin trans mod_entry *does some internal ops* commit end trans 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 one master. > 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. -- William <william@xxxxxxxxxxxxxxx> -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
