I've moved to new (FAST*) hardware and I was testing how long it took for a empty mirrormode server to catch up with the other one. (like after a complete failure of one of the nodes)
I'm using a database where id2entry.bdb is ~6.6Gb. and it's taking surprisingly long time. After 18 hours it has gotten around 1/4 of the way.
I'm wondering if I could speed it up by loading an LDIF backup on the empty server before I start it. Are there anything special I should take into account, like regarding entryCSN and options to slapdadd when I load the backup?
/Peter
--On Thursday, October 29, 2009 5:02 PM +0100 Peter Mogensen apm@mutex.dk wrote:
I've moved to new (FAST*) hardware and I was testing how long it took for a empty mirrormode server to catch up with the other one. (like after a complete failure of one of the nodes)
I'm using a database where id2entry.bdb is ~6.6Gb. and it's taking surprisingly long time. After 18 hours it has gotten around 1/4 of the way.
I'm wondering if I could speed it up by loading an LDIF backup on the empty server before I start it.
Yep. This is the recommended method for large databases.
Are there anything special I should take into account, like regarding entryCSN and options to slapdadd when I load the backup?
You should make sure and use the -q flag, and make sure you have a properly configured DB_CONFIG file that will hold the entire DB (not just the id2entry.bdb file size). In addition, if you go over 8GB in size, you'll likely want to use a shared memory key instead of an on disk cache.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
I'm using a database where id2entry.bdb is ~6.6Gb. and it's taking surprisingly long time. After 18 hours it has gotten around 1/4 of the way.
I'm wondering if I could speed it up by loading an LDIF backup on the empty server before I start it.
Yep. This is the recommended method for large databases.
Ok. - one thing which makes me wonder though: If I monitor the process with "slapcat | grep 'dn: o=' | wc -l" to get an estiamte of how much has been replicated, it sometimes decreases !?!?
The database has a lot of nodes (~160.000) below the root with DN o=...
Is it expected that that number will not be strictly rising, or is it a sign that there's some other thing going on making it slow?
/Peter
openldap-software@openldap.org