Noriko, Please see my comments below. On Thu, 14 Oct 2010, Noriko Hosoi wrote: > Eric, > > Thanks for your input. It contains lots of useful information. Can I > ask some more details about this section? The corrupted DN problem is > observed only on a replica after a consumer initialization is done? Or > it is observed on the master as well? It is mainly observed on the master. I think I only observed it on the replica because I happened to be doing an initialization at a time when the master had some of the corrupted DNs in memory. On the master, the corrupted DNs can be cleared by a restart - they seem to be in memory only. To fix the replica, I had to reinitialize again after restarting the master (because the entries with corrupt DNs were written to disk.) I think the source of the error on the replica was just that it was passed bad information from the master. > When the incorrect DNs are > detected in the consumer initialization, it is rejected due to the > invalid DN or just passed through? Many were just passed though because they were actually valid, but incorrect DNs, in the case where the ou=Group part was dropped from the DN: dn: cn=mongrp,dc=acs,dc=albany,dc=edu A few were rejected because the DN was invalid, like in the case of wwwcarey,=albany,,dc=acs,dc=albany,dc=edu > Were the events logged in the error > log? For the rejected DNs, yes: [14/Oct/2010:10:35:35 -0400] NSMMReplicationPlugin - multimaster_be_state_change : replica dc=acs,dc=albany,dc=edu is going offline; disabling replication [14/Oct/2010:10:35:35 -0400] - WARNING: Import is running with nsslapd-db-privat e-import-mem on; No other process is allowed to access the database [14/Oct/2010:10:35:56 -0400] - import userRoot: Processed 50368 entries -- avera ge rate 2398.5/sec, recent rate 2398.4/sec, hit ratio 0% [14/Oct/2010:10:36:00 -0400] - import userRoot: WARNING: Skipping entry "cn=wwwc hsr,ou=Group,ou=Group,dc=acs,dc=albany,dc=edu" which has no parent, ending at line 0 of file "(bulk import)" [14/Oct/2010:10:36:01 -0400] - import userRoot: WARNING: bad entry: ID 57588 ... [14/Oct/2010:10:36:08 -0400] - import userRoot: WARNING: Skipping entry "cn=wwwtmu,ou=Group,=albany,dc=edu,dc=acs,dc=albany,dc=edu" which has no parent, ending at line 0 of file "(bulk import)" [14/Oct/2010:10:36:09 -0400] - import userRoot: WARNING: bad entry: ID 72233 ... [14/Oct/2010:10:36:39 -0400] - import userRoot: Processed 107643 entries -- aver age rate 1708.6/sec, recent rate 1363.7/sec, hit ratio 95% [14/Oct/2010:10:36:47 -0400] - import userRoot: WARNING: Skipping entry "cn=wwwc arey,=albany,,dc=acs,dc=albany,dc=edu" which has no parent, ending at line 0 of file "(bulk import)" [14/Oct/2010:10:36:48 -0400] - import userRoot: WARNING: bad entry: ID 116490 >Did you have a chance to search the entry having the corrupted DN > (corrupted and original one) on the master then? Yes. The same DNs showed up corrupted on the master, until I restarted it. Then they appeared fine. So far, the corrupted DNs seem to be happening less frequently with 1.2.6.1, as compared to 1.2.6. We have been on 1.2.6.1 since yesterday evening, and only had this happen once so far with some of the group entries. On 1.2.6, this was usually happening multiple times per day, and affecting user entries. Thanks, Eric
