https://bugzilla.redhat.com/show_bug.cgi?id=590826
Description of problem: Had issues and reinstalled 2 new masters gtedm1.iam gtedm2.iam. Now if we restart either new master, we get this error in the error log. Reinitializing doesnt matter. If we reinitialize from a presumably clean master (gertrude.iam), we still get this result. [10/May/2010:14:47:01 -0400] - slapd stopped. 389-Directory/1.2.2 B2009.237.2054 gtedm3.iam.gatech.edu:636 (/etc/dirsrv/slapd-gtedm3) [10/May/2010:14:47:12 -0400] - 389-Directory/1.2.2 B2009.237.2054 starting up [10/May/2010:14:47:13 -0400] - cache autosizing. found 2059480k physical memory [10/May/2010:14:47:13 -0400] - cache autosizing: db cache: 617844k, each entry cache (4 total): 123568k [10/May/2010:14:47:14 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data for replica ou=people,dc=gted,dc=gatech,dc=edu was reloaded and it no longer matches the data in the changelog (replica data > changelog). Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [10/May/2010:14:47:14 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data for replica dc=gted,dc=gatech,dc=edu was reloaded and it no longer matches the data in the changelog (replica data > changelog). Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [10/May/2010:14:47:14 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data for replica ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu was reloaded and it no longer matches the data in the changelog (replica data > changelog). Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [10/May/2010:14:47:15 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [10/May/2010:14:47:15 -0400] - Listening on All Interfaces port 636 for LDAPS requests [root@gtedm3 slapd-gtedm3]# Version-Release number of selected component (if applicable): 389-Directory/1.2.2 B2009.237.2054 How reproducible: Any time we do dirsrv stop then start. we see it on gtedm1 and gtedm2 Steps to Reproduce: 1. stop and start one of the new masters (reinitializig them doesnt help) 2. 3. Actual results: Expected results: Additional info:
commit changeset:6bac1a7/389-ds-base Author: Rich Megginson rmeggins@redhat.com Date: Thu Sep 8 20:03:14 2011 -0600 Reviewed by: nkinder, nhosoi (Thanks!) Branch: master Fix Description: When there are obsolete or decommissioned masters in the RUV, this should not invalidate the changelog. Instead, warn the user that there are replicas in the database RUV that are not in the changelog max RUV. In this case, the CLEANRUV task can be used to remove the obsolete masters from the database RUV. I had to add a function to generate a string representation of the replica RUVElement* for logging purposes, and used that function elsewhere. The new function ruv_compare_ruv should be used instead of ruv_contains_ruv since it gives more flexibility about logging and handling different cases. Platforms tested: RHEL6 x86_64 Flag Day: no
Added initial screened field value.
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: 1.2.10
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/248
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.