Am Mi., 16. März 2022 um 21:39 Uhr schrieb Quanah Gibson-Mount quanah@fast-mail.org:
--On Wednesday, March 16, 2022 10:23 PM +0100 Meike Stone meike.stone@googlemail.com wrote:
We are still using the bdb backend and the latest 2.4.59 (don't ask, it will be replaced soon) and I remember, a "few" years ago, I had problems with slapcat and online databases, because the server was stucking for a while and answers were delayed .. (The Admin Guide tells, that "Backups are managed slightly differently" ...) Secondly, while offline, I can copy the whole database directory including the transaction logs ..
Ah, ok. Yes, you could set up a read-only consumer node to take backups from. I'd highly prioritize moving to a supported release of OpenLDAP with the back-mdb backend as well (I see you say it should be replaced soon). :)
Oh my god, almost a year has passed - now finally our department wants to migrate to the latest version 2.5.14. I'm responsible for the Master LDAP-Server, but there are a few ro-replicas in other departments where I'm not responsible - and I have no access. Is it possible to migrate the master server to the new version and update the replicas (running 2.4.59) later, independent from the master (migration)? Are there any problems to be expected?
Regards and many thanks Meike
On 08Mar23 17:48+0100, Meike Stone wrote:
Oh my god, almost a year has passed - now finally our department wants to migrate to the latest version 2.5.14. I'm responsible for the Master LDAP-Server, but there are a few ro-replicas in other departments where I'm not responsible - and I have no access.
That's an unfortunate condition.
Is it possible to migrate the master server to the new version and update the replicas (running 2.4.59) later, independent from the master (migration)? Are there any problems to be expected?
I can tell from my recent experiences: I upgraded our infrastructure from 2.4.48 to 2.6.3 and had syncrepl (no delta sync) running between different slapd versions; where sync-consumers where first upgraded to 2.6.3 and sync-providers remained on 2.4.48. Upgrade was done by synching a fresh copy of the DB. After that, the two providers (mirror pair) went to 2.6.3 in the same manner.
I tested all this in advance before doing the stunt on production. Went all fine here with zero downtime and slapcat/add was not used.
back-mdb was already in place, but maybe this procedure might give you an idea when thinking about upgrading your systems. And just to repeat that previous and important paragraph: I tested everthing in advance so I felt confident while doing it during production. I suggest you do testing as well.
HIH,
openldap-technical@openldap.org
-
Bastian Tweddell -
Meike Stone