[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd, bdb, 32-bit -> 64-bit

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, 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?

--
Frode Nordahl