Hi,
According to dirsrv docs [1] referential integrity should only be enabled on a single server in a MMR scenario.
My topology is:
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? What are the potential issues of enabling this on multiple hosts? In the future what would need to change in the plugin to support enabling on multiple hosts if not already possible?
[1]: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/h...
----- Original Message -----
From: "William" william@firstyear.id.au To: 389-users@lists.fedoraproject.org Sent: Wednesday, 4 March, 2015 5:54:50 AM Subject: [389-users] Referential Integrity
Hi,
According to dirsrv docs [1] referential integrity should only be enabled on a single server in a MMR scenario.
My topology is:
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.
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.
Perhaps someone else in this alias could give more precise answers ?
Thanks and regards,
German.
-- William william@firstyear.id.au
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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.
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.
Looks like someone already did this.
nsslapd-pluginAllowReplUpdates
It looks like there is no documentation about how this config value works though: and the values it influences aren't widely through the code so I can't confirm if it's a finished feature.
If you set this on the plugin, to "on" (I think it defaults to off), then on certain operations the integrity checks are bypassed on replicated operations.
You can see this on line 726 of ds/ldap/servers/plugins/referint/referint.c
Can someone confirm if how I'm interpreting this is correct, and if we should open a documentation bug to get this documented?
On 03/15/2015 07:14 PM, William wrote:
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.
Looks like someone already did this.
nsslapd-pluginAllowReplUpdates
It looks like there is no documentation about how this config value works though: and the values it influences aren't widely through the code so I can't confirm if it's a finished feature.
It is finished, and I will write a design document for it on the wiki (port389.org).
If you set this on the plugin, to "on" (I think it defaults to off), then on certain operations the integrity checks are bypassed on replicated operations.
You can see this on line 726 of ds/ldap/servers/plugins/referint/referint.c
Can someone confirm if how I'm interpreting this is correct, and if we should open a documentation bug to get this documented?
So, by setting this to "on", it allows delete operations that come from replication to be processed by the RI plugin. Usually the RI plugin ignores replicated delete operations because it is assumed the supplier replica has the RI plugin enabled, and it has already performed the group cleanup(and those changes are replicated). So there is no need to do it twice. However, there are some scenarios where the supplier might NOT have enabled the RI plugin. In this case we do want the local RI plugin to process the replicated delete operation, and this is where this setting would come into play.
Mark
nsslapd-pluginAllowReplUpdates
It looks like there is no documentation about how this config value works though: and the values it influences aren't widely through the code so I can't confirm if it's a finished feature.
It is finished, and I will write a design document for it on the wiki (port389.org).
Thanks for that. I'd like to look at this document once you are done.
Can someone confirm if how I'm interpreting this is correct, and if we should open a documentation bug to get this documented?
So, by setting this to "on", it allows delete operations that come from replication to be processed by the RI plugin. Usually the RI plugin ignores replicated delete operations because it is assumed the supplier replica has the RI plugin enabled, and it has already performed the group cleanup(and those changes are replicated). So there is no need to do it twice. However, there are some scenarios where the supplier might NOT have enabled the RI plugin. In this case we do want the local RI plugin to process the replicated delete operation, and this is where this setting would come into play.
So in the case of having RI on two ldap servers, you would set this to off, since the server that handled the delete will replicate the other updates soon after. In the case of RI on a single server, when the non-RI server issues a delete, the RI enabled server would be triggered to run the RI checks. Is that correct?
Given that you seem to be quite familiar with the refint code, can you comment on the ability to run two masters with both having the plugin enabled?
On 03/16/2015 06:50 PM, William wrote:
nsslapd-pluginAllowReplUpdates
It looks like there is no documentation about how this config value works though: and the values it influences aren't widely through the code so I can't confirm if it's a finished feature.
It is finished, and I will write a design document for it on the wiki (port389.org).
Thanks for that. I'd like to look at this document once you are done.
Can someone confirm if how I'm interpreting this is correct, and if we should open a documentation bug to get this documented?
So, by setting this to "on", it allows delete operations that come from replication to be processed by the RI plugin. Usually the RI plugin ignores replicated delete operations because it is assumed the supplier replica has the RI plugin enabled, and it has already performed the group cleanup(and those changes are replicated). So there is no need to do it twice. However, there are some scenarios where the supplier might NOT have enabled the RI plugin. In this case we do want the local RI plugin to process the replicated delete operation, and this is where this setting would come into play.
So in the case of having RI on two ldap servers, you would set this to off, since the server that handled the delete will replicate the other updates soon after. In the case of RI on a single server, when the non-RI server issues a delete, the RI enabled server would be triggered to run the RI checks. Is that correct?
Correct, but the RI enabled server needs to have nsslapd-pluginAllowReplUpdates set to "on" if there are any other master/supplier replication servers that do not have RI plugin enabled.
Given that you seem to be quite familiar with the refint code, can you comment on the ability to run two masters with both having the plugin enabled?
This is the preferred way, and requires no "special" configuration steps. Ideally all the servers in a replicated deployment should have the same plugin configurations. It's when server configurations are not the same that you can run into issues(e.g. needing to set nsslapd-pluginAllowReplUpdates to "on", etc).
So in the case of having RI on two ldap servers, you would set this to off, since the server that handled the delete will replicate the other updates soon after. In the case of RI on a single server, when the non-RI server issues a delete, the RI enabled server would be triggered to run the RI checks. Is that correct?
Correct, but the RI enabled server needs to have nsslapd-pluginAllowReplUpdates set to "on" if there are any other master/supplier replication servers that do not have RI plugin enabled.
Thanks for making sure I was clear on this.
Given that you seem to be quite familiar with the refint code, can you comment on the ability to run two masters with both having the plugin enabled?
This is the preferred way, and requires no "special" configuration steps. Ideally all the servers in a replicated deployment should have the same plugin configurations. It's when server configurations are not the same that you can run into issues(e.g. needing to set nsslapd-pluginAllowReplUpdates to "on", etc).
Interesting. All the Redhat 389 documentation states that you should NOT enable this on multiple masters. Is this recommendation in the documentation something that should be reviewed?
On 03/17/2015 06:11 PM, William wrote:
So in the case of having RI on two ldap servers, you would set this to off, since the server that handled the delete will replicate the other updates soon after. In the case of RI on a single server, when the non-RI server issues a delete, the RI enabled server would be triggered to run the RI checks. Is that correct?
Correct, but the RI enabled server needs to have nsslapd-pluginAllowReplUpdates set to "on" if there are any other master/supplier replication servers that do not have RI plugin enabled.
Thanks for making sure I was clear on this.
Given that you seem to be quite familiar with the refint code, can you comment on the ability to run two masters with both having the plugin enabled?
This is the preferred way, and requires no "special" configuration steps. Ideally all the servers in a replicated deployment should have the same plugin configurations. It's when server configurations are not the same that you can run into issues(e.g. needing to set nsslapd-pluginAllowReplUpdates to "on", etc).
Interesting. All the Redhat 389 documentation states that you should NOT enable this on multiple masters. Is this recommendation in the documentation something that should be reviewed?
Yeah this is probably outdated. In the RI plugin there is specific code to ignore replicated operations (hence the reason for the new config setting). By default this will all work just fine, the config setting is only for corner cases where the masters do not have the RI plugin enabled, but the hubs/consumers do.
I'll be including this in the my write up. Hopefully I can get it done this week.
389-users@lists.fedoraproject.org
-
German Parente -
Mark Reynolds -
William