On Mon, 2017-11-27 at 18:12 -0500, Paul Whitney wrote: > 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. I'm very curious and concerned about this downgrade issue, so I'll speak to some people here about what we can do to make this more robust. Thanks for your feedback mate, glad that I could help you, > > Paul M. Whitney > paul.whitney@xxxxxxx > > Sent from my Mac Book Pro > > > On Nov 22, 2017, at 08:38, William Brown <wibrown@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject > > .org > > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
