On Monday 16 October 2006 09:56, Frode Nordahl wrote: > On 16. okt. 2006, at 03.08, matthew sporleder wrote: > >> > And you can definitely add new replicas without causing any > >> > >> downtime > >> > >> > by using the strategy you're suggesting- even using slapcat/ > >> > >> slapadd. > >> > >> Yes, this would be possible, but as the slapadd step may take several > >> hours I cannot rely on this. I have tested it with slapadd -q and it > >> still takes too long. There just is alot of data that must go in > >> there :-) > > > > Use the same binary set on all of your replicas, otherwise you can't > > reasonably expect the same database files to work. > > There is nothing in Berkeley DB that prevents you from doing this, > hence the question. But I have learned that it is a deliberate > decision behind this not working, and I am content with knowing that. > > > I also have a large database (my slapcat-ed file is over 4gb), but I > > don't see how it's more reliable to shutdown a spare for one hour > > while you scp versus four hours while you slapadd. What's the > > difference? A minute's worth of replication to catch-up with? > > I would have to take the slave down to do the slapcat as well, No, you can slapcat while the slave is running. > and I > guess the time difference between slapcat and tar of the binary files > is next to nil. > > The whole point for having the spare slave is to take it down at the > same time as I add a new replica to the master servers configuration. > That way the slapcat / binary copy will be in a good state, and the > replication will start at the right spot. > > As soon as the slapcat or binary copy is done the replication can > start on the slave again. > > I can probably evade this by using syncrepl instead? Yes, if you're using sync-repl, there is no need for this. Take any valid snapshot of the database, slapadd on the consumer, start it up, and it will catch up. Or, if you can wait a little bit longer, skip the whole slapcat/slapadd step entirely. Regards, Buchan -- Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpfP8pPqezH6.pgp
Description: PGP signature