Adding another Master is not an option because for the end result the IP 
address and dns record of the master should be same. I did try to swap the 
hardware on the existing Master after stopping writes and making sure that the 
db was in sync. After recreating replication agreements with the hubs, it is 
now complaining that the hubs have a different generation id, hence won't 
replicate.




On Dec 16, 2012, at 6:52 AM, "Dan Lavu" <d...@lavu.net<mailto:d...@lavu.net>> 
wrote:

You do not have to init the database as long as they are in sync, you can just 
'send updates'. If all the slaves are 1.1.2, you'd want to eventually upgrade 
those machines too, have you considered just adding another master 
(master/master) then sliding the original master out? Should equate to zero 
downtime.

On Dec 14, 2012, at 6:53 PM, Shardul Kerkar 
<sker...@accessline.com<mailto:sker...@accessline.com>> wrote:

Hi Folks,

I have recently  been tasked with moving a Single Ldap Master from a dying 
machine to a spanking new blade. After doing some research it appears to me 
that the optimum way to do this will be installing a fresh instance of the 
application on the new server, import the database and then recreate and 
reinitialize all the hubs and replicas. The problem I face is that this work 
place has a humongous LDAP database will 3 mil+ entries. Re-initialization is 
taking upto 3 hours in some cases. With 5 hubs and 20 replicas to reinitialize, 
the downtime is unacceptable to the client.

If I stop writes to the Master, then export the database to the new box and 
recreate the New-Master-Hub replication after removing the old Master , will I 
still need to re-initialize the hubs? Is there any way to do this swap without 
reinitializing or fooling the hubs and reps into thinking that they are still 
talking to the same Master albeit on a new machine (same ip address/dns).

The client is still using ver. 1.1.2 on Centos 5.4

Thanks,
Shar Ker
--
389 users mailing list
389-users@lists.fedoraproject.org<mailto:us...@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users

<ATT00001..c>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Reply via email to