[389-users] fresh replica reports "reloading ruv failed " just after successfull initialization.

Rich Megginson rmeggins at redhat.com
Mon Jun 24 15:00:19 UTC 2013


On 06/22/2013 03:58 PM, Jovan.VUKOTIC at sungard.com wrote:
>
> Hi,
>
> We have four 389 DS, version 1.2.11 that we are organizing in 
> multi-master replication topology.
>
> After I enabled all four multi-master replicas and initialized them - 
> from the one, referent replica M1 and Incremental Replication started, 
> it turned out that only two of them are included  in replication, the 
> referent M1 and M2 (replication is working in both direction)
>
> I tried to fix M3 and M4 in the following way:
>
> M3 example:
>
> removed replication agreement M1-M3 (M2-M3 did not existed, M4 
> switched off)
>
> After several database restores of pre-replication state and 
> reconfiguration of that replica, I removed 389 DS instance M3 
> completely and reinstalled it again: remove-ds-admin.pl + 
> setup-ds-admin.pl. I configured TLS/SSL (as before), restarted the DS 
> and enabled replica from 389 Console.
>
> Then I returned to M1, recreated the agreement and did  initialization 
> of M3. It was successful again, in terms that M3 imported all the 
> data, but immediately after that, to me strange errors were reported:
>
> What confuses me is that LDAP 68 means that an entry already exits… 
> even if it is a new replica. Why a tombstone?
>
> Or to make the long story short: Is the only remedy to reinstall all 
> four replica again?
>

Try doing an online init of this replica from a "good" master.

> 22/Jun/2013:16:30:50 - 0400]     — All database tnreaas now 
> stopped                      // this is from a backup done before 
> replication configuration
>
> [22/Jun/2013:16:43:25 —0400] NSMMReplicationPlugin — 
> multimaster_be_state_change: replica xxxxxxxxxx  is going off line; 
> disablin
>
> g replication
>
> [22/Jun/2013:16:43:25 —0400] — entrycache_clear_int: there are still 
> 20 entries in the entry cache,
>
> [22/Jun/2013:16:43:25 —0400] — dncache_clear_int: there are still 20 
> dns in the dn cache. :/
>
> [22/Jun/2013:16:43:25 —0400] — WARNING: Import is running with 
> nsslapd—db—private—import—mem on; No other process is allowed to access th
>
> e database
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Workers finished; 
> cleaning up..
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Workers cleaned up.
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Indexing complete. 
> Post—processing...
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Generating 
> numSubordinates complete.
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Flushing caches.
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Closing files.
>
> [22/Jun/2013:16:43:30 —0400] — entrycache_clear_int: there are still 
> 20 entries in the entry cache.
>
> [22/Jun/2013:16:43:30 —0400] — dncache_clear_int: there are still 917 
> dn’s in the dn cache. :/
>
> [22/Jun/2013:16:43:30 —0400] — import userRoot: Import complete. 
> Processed 917 entries in 4 seconds, (229.25 entries/sec)
>
> [22/Jun/2013:16:43:30 —0400] NSMMRep1 icationPlugin — 
> multimaster_be_state_change: replica xxxxxxxxxxx is coming online; 
> enabling
>
> replication
>
> [22/Jun/2013:16:43:30 —0400] NSMMReplicationPlugin — 
> replica_configure_ruv: failed to create replica ruy tombstone entry 
> (xxxxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:43:30 —0400] NSMMReplicationPlugin — 
> replica_enable_replication: reloading ruv failed
>
> [22/Jun/2013:16:43:32 —0400] NSMMReplicationPlugin — 
> _replica_configure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:44:02 —0400] NSMMReplicationPlugin — 
> replica_configure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:44:32 —0400] NSMMReplicationPlugin — 
> _replica_configure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:45:02 —0400] NSMMReplicationPluyin — 
> _replica_confiyure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:45:32 —0400] NSMMReplicationPlugin — 
> _replica_configure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxxx); LDAP error — 68
>
> [22/Jun/2013:16:46:02 —0400] NSMMReplicationPlugin — 
> _replica_configure_ruv: failed to create replica ruv tombstone entry 
> (xxxxxxxxx); LDAP error — 68
>
> Any help will be appreciated.
>
> Thank you.
>
> *Jovan Vukotić* • Senior Software Engineer • Ambit Treasury Management 
> • SunGard • Banking • Bulevar Milutina Milankovića 136b, Belgrade, 
> Serbia • tel: +381.11.6555-66-1 • jovan.vukotic at sungard.com 
> <mailto:jovan.vukotic at sungard.com>
>
> Description: Description: Description: Description: Description: 
> coc-signature-03-2012 
> <http://www.capitalize-on-change.com/?email=70150000000Y1Et>
>
> *Join the online conversation with SunGard’s customers, partners and 
> Industry experts and find an event near you at: **www.sungard.com/ten* 
> <http://www.capitalize-on-change.com/?email=70150000000Y1Et>*. *
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130624/bff03d0a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 8696 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130624/bff03d0a/attachment.gif>


More information about the 389-users mailing list