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?
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.
Paul M. Whitney E-mail: paul.whitney@mac.com Cell: 410.493.9448 Sent from my browser.
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.
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.whitney@mac.com
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 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-leave@lists.fedoraproject.org
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@mac.com
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 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-leave@lists.fedoraproject .org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o rg
389-users@lists.fedoraproject.org
-
Paul Whitney -
William Brown