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

Sent from my Mac Book Pro

On Nov 22, 2017, at 08:38, William Brown <wibrown@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
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
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 and 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.


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-leave@lists.fedoraproject.org