William, Thank you for your suggestion. Exporting the databases from a working master with the “-r” option worked and I was able to get the three bad servers back up and in replication.
Paul M. Whitney paul.whit...@mac.com Sent from my Mac Book Pro > On Nov 22, 2017, at 08:38, William Brown <wibr...@redhat.com> wrote: > > On Wed, 2017-11-22 at 13:30 +0000, Paul Whitney wrote: >> We have a few new servers deployed with 389-ds-base version 1.3.5.10- >> 21. These servers were deployed in an environment where auto- >> patching happens and we forgot to disable that feature. >> >> Overnight the servers were updated to 389-ds-base version 1.3.6.1- >> 19. All of the upgraded servers are now in a bad state. We have >> tried multiple ways to reinitialize them but cannot seem to get the >> servers to work again. We do see in the logs when they d startup >> "Abnormal shutdown detected, rebuilding database". But then the >> server stays in that state and does nothing that I can tell other >> than touch the timestamp on the __DB files. >> >> Are versions 1.3.5.10-21 and 1.3.6.1-19 not compatible? Can anyone >> suggest a way to reinit these servers without having to rebuild them? > > As far as I am aware, a downgrade *should* work, but we don't often > advise it. Are you saying the upgrade itself failed? Or downgrade? This > is certainly the first I'm hearing of an upgrade failure ... > > The database format has not changed that I am aware of, and the content > of dse.ldif also hasn't changed (any changes should be "in memory" > anyway due to the new libglobs features in 1.3.6). > >> >> Reinit has been attempted by doing the following methods: >> >> - Console reinit. (Failed, cannot connect to server) >> - Export replica for the server. (Import successful, however gets >> into the "rebuild database" state. >> - Copied the entire instance (/var/lib/dirsrv/slapd-myinstance) and >> restart. Same state as the one above. >> >> > > I think I'd need to see the error log to be sure of the error you are > seeing at start to advise further. > > If you can't provide that, consider a db2ldif -r from a working master, > and then 'ldif2db' on a broken server. IIRC you can't just copy the > /var folder because of the change log, but I could be wrong about this. > > > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
