You may also split the database in smaller bits, unless it has to be exactly one naming context (I don't recall if 2.1 already had the glue capability).
p. > Gentoo with a 2.6.5 kernel, glibc 2.3.3, openldap 2.1.30. It's doing > this on 4 identical systems and 1 with a 2.6.9 kernel, so my > configuration is somehow very wrong. > > System setup: admin1 is the master and replicates out to ldap1 and > ldap2. Directory listings are at the end of the email. > > Last night, an ldap server died with the (non-exact) error unable to > write to gdbm. The id2entry.gdbm file was a byte below 2 Gigs. In > subsequent testing with dd, I cannot create a file bigger than > 2*1024*1024*1024 bytes. Could someone please verify that: > a) I need to rebuild something like glibc. > b) I do not need to rebuild openldap. > > Any questions or comments are appreciated. Any suggestions are greatly > appreciated. URL's welcome! > > Things I won't do unless can prove absolutely necessary: > a) switch to bdb (will require a rebuild of openldap to bring in > whatever is necessary to make it stable, still won't solve the problem > if _that_ db ever gets to 2 GB) > b) upgrade kernel > > I was able to recover the system by rsyncing the id2entry.gdbm from > the other slave and reindexing. Here is what I have now: > total 2117264 > -rw------- 1 ldap ldap 57353 Jul 6 09:35 cn.gdbm > -rw------- 1 ldap ldap 11165800 Jul 6 09:36 dn2id.gdbm > -rw------- 1 ldap ldap 65545 Jul 6 09:35 gidNumber.gdbm > -rw------- 1 ldap ldap 2147368403 Jul 6 09:36 id2entry.gdbm > -rw------- 1 ldap ldap 2768924 Jul 6 09:35 mail.gdbm > -rw------- 1 ldap ldap 12288 Sep 8 2004 memberUid.gdbm > -rw------- 1 ldap ldap 12296 Jul 6 09:09 nextid.gdbm > -rw------- 1 ldap ldap 367661 Jul 6 09:35 objectClass.gdbm > -rw------- 1 ldap ldap 12896 Oct 18 2004 > sendmailMTAAliasGrouping > .gdbm > -rw------- 1 ldap ldap 12304 Sep 8 2004 > sendmailMTAClassName.gdb > m > -rw------- 1 ldap ldap 98313 Oct 13 2004 > sendmailMTACluster.gdbm > -rw------- 1 ldap ldap 12304 Sep 8 2004 > sendmailMTAHost.gdbm > -rw------- 1 ldap ldap 2813968 Jul 6 09:36 > sendmailMTAKey.gdbm > -rw------- 1 ldap ldap 98313 Sep 8 2004 > sendmailMTAMapName.gdbm > -rw------- 1 ldap ldap 12884 Sep 8 2004 sn.gdbm > -rw------- 1 ldap ldap 659456 Jul 6 09:35 uid.gdbm > -rw------- 1 ldap ldap 331888 Jul 6 09:35 uidNumber.gdbm > > Once that file hits 2 Gigs though, I am dead in the water :-( > > For history, I had severe stability problems when trying to use bdb > (just read-only). It would lock up several times per day. Switched to > ldbm and has been solid as a rock since then. > -- > Regards... Todd > Well, it's Karch... --frequently heard after every amazing move he does > Linux kernel 2.6.11-6mdksmp 2 users, load average: 0.12, 0.10, 0.07 > -- Pierangelo Masarati mailto:[EMAIL PROTECTED] SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
