Hi Everyone,
One of my colleagues is working on a LDAP cluster that has a recent failure of one of the mult-imasters in a 2 node cluster. We have reinitialized the failed host and found that a bunch of entries are being dropped during the replication. Those entries display the following message:
WARN - import_fifo_fetch - import userRoot: Bad entry: ID XXXX WARN - import_foreman - import userRoot: Skipping entry "XXXXXXXXXXX" which has no parent, ending at line 0 of file "(bulk import)"
We can see that the entry exists and does have a parent on the source.
On 6 Mar 2019, at 07:59, Jason Jenkins jjenkins@threatmetrix.com wrote:
Hi Everyone,
One of my colleagues is working on a LDAP cluster that has a recent failure of one of the mult-imasters in a 2 node cluster. We have reinitialized the failed host and found that a bunch of entries are being dropped during the replication. Those entries display the following message:
WARN - import_fifo_fetch - import userRoot: Bad entry: ID XXXX WARN - import_foreman - import userRoot: Skipping entry "XXXXXXXXXXX" which has no parent, ending at line 0 of file "(bulk import)"
We can see that the entry exists and does have a parent on the source.
Hi there,
What versions of the server are you running, and what distro? That would be a good start for us to see these.
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs
Red Hat Enterprise Linux Server release 6.5 RedHat Directory Server ver: 1.2.11.15
We are in the process of upgrading the OS and Directory Server by adding new hosts to the cluster and decommissioning the older hosts. Before we could even start that, One of the multi-master nodes failed. We've gone through replicating to the failed node and to an upgraded host. We get the "Skipping entry" warnings resulting in dropped entries.
On 3/5/19, 4:01 PM, "William Brown" wbrown@suse.de wrote:
> On 6 Mar 2019, at 07:59, Jason Jenkins jjenkins@threatmetrix.com wrote: > > Hi Everyone, > > One of my colleagues is working on a LDAP cluster that has a recent failure of one of the mult-imasters in a 2 node cluster. We have reinitialized the failed host and found that a bunch of entries are being dropped during the replication. Those entries display the following message: > > > WARN - import_fifo_fetch - import userRoot: Bad entry: ID XXXX > WARN - import_foreman - import userRoot: Skipping entry "XXXXXXXXXXX" which has no parent, ending at line 0 of file "(bulk import)" > > > We can see that the entry exists and does have a parent on the source. >
Hi there,
What versions of the server are you running, and what distro? That would be a good start for us to see these.
> _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 6 Mar 2019, at 10:30, Jason Jenkins jjenkins@threatmetrix.com wrote:
Red Hat Enterprise Linux Server release 6.5 RedHat Directory Server ver: 1.2.11.15
We are in the process of upgrading the OS and Directory Server by adding new hosts to the cluster and decommissioning the older hosts. Before we could even start that, One of the multi-master nodes failed. We've gone through replicating to the failed node and to an upgraded host. We get the "Skipping entry" warnings resulting in dropped entries.
Thanks. I asked about the version because I seem to remember (but don’t quote me on this), hearing about this issue being solved somewhere in the 1.3.x series, probably about 1.3.6ish at a guess.
If I recall, it comes about because the entries are sent in “entryid order”, but if you had:
ou=foo,dc=bar (entry id 1) ou=baz,dc=bar (entry id 2)
Then you modrdn these such as:
ou=foo,ou=baz,dc=bar
ou=foo,ou=baz,dc=bar is “id 1” so is sent first, but it’s parent ou=baz hasn’t been sent yet.
First step in any situation like this: take back ups of the good remaining server :) db2bak and db2ldif -r if possible.
After that, I’d say to restore the other host, load the ldif from the good master you created with “db2ldif -r”, with “ldif2db”, and see if replication is able to start from there.
If not, we’ll have to investigate further.
Hope this helps
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs
Thanks. I'll give that a try.
On 3/5/19, 4:43 PM, "William Brown" wbrown@suse.de wrote:
> On 6 Mar 2019, at 10:30, Jason Jenkins jjenkins@threatmetrix.com wrote: > > > > Red Hat Enterprise Linux Server release 6.5 > RedHat Directory Server ver: 1.2.11.15 > > We are in the process of upgrading the OS and Directory Server by adding new hosts to the cluster and decommissioning the older hosts. Before we could even start that, One of the multi-master nodes failed. We've gone through replicating to the failed node and to an upgraded host. We get the "Skipping entry" warnings resulting in dropped entries. >
Thanks. I asked about the version because I seem to remember (but don’t quote me on this), hearing about this issue being solved somewhere in the 1.3.x series, probably about 1.3.6ish at a guess.
If I recall, it comes about because the entries are sent in “entryid order”, but if you had:
ou=foo,dc=bar (entry id 1) ou=baz,dc=bar (entry id 2)
Then you modrdn these such as:
ou=foo,ou=baz,dc=bar
ou=foo,ou=baz,dc=bar is “id 1” so is sent first, but it’s parent ou=baz hasn’t been sent yet.
First step in any situation like this: take back ups of the good remaining server :) db2bak and db2ldif -r if possible.
After that, I’d say to restore the other host, load the ldif from the good master you created with “db2ldif -r”, with “ldif2db”, and see if replication is able to start from there.
If not, we’ll have to investigate further.
Hope this helps
— Sincerely,
William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Hi Guys,
Recently I had the same issue and I copied the database backup from one server to another and used ldif2db.pl to import it and worked fine. After that, the replication works fine.
Hope that helps you.
On Wed, Mar 6, 2019 at 5:24 PM Jason Jenkins jjenkins@threatmetrix.com wrote:
Thanks. I'll give that a try.
On 3/5/19, 4:43 PM, "William Brown" wbrown@suse.de wrote:
> On 6 Mar 2019, at 10:30, Jason Jenkins <jjenkins@threatmetrix.com>
wrote: > > > > Red Hat Enterprise Linux Server release 6.5 > RedHat Directory Server ver: 1.2.11.15 > > We are in the process of upgrading the OS and Directory Server by adding new hosts to the cluster and decommissioning the older hosts. Before we could even start that, One of the multi-master nodes failed. We've gone through replicating to the failed node and to an upgraded host. We get the "Skipping entry" warnings resulting in dropped entries. >
Thanks. I asked about the version because I seem to remember (but
don’t quote me on this), hearing about this issue being solved somewhere in the 1.3.x series, probably about 1.3.6ish at a guess.
If I recall, it comes about because the entries are sent in “entryid
order”, but if you had:
ou=foo,dc=bar (entry id 1) ou=baz,dc=bar (entry id 2) Then you modrdn these such as: ou=foo,ou=baz,dc=bar ou=foo,ou=baz,dc=bar is “id 1” so is sent first, but it’s parent
ou=baz hasn’t been sent yet.
First step in any situation like this: take back ups of the good
remaining server :) db2bak and db2ldif -r if possible.
After that, I’d say to restore the other host, load the ldif from the
good master you created with “db2ldif -r”, with “ldif2db”, and see if replication is able to start from there.
If not, we’ll have to investigate further. Hope this helps — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
389-users@lists.fedoraproject.org