Re: Stanford moves to OL 2.2.6 for production

[dbroady@lexmark.com]

Quanah,

Thanks for the comment about the move from Hash to Btree indices, as well
as your performance metrics.  I wonder what the reasoning was for doing
this.  Developers, any answers on this?

If you want to re-enable the Hash indexing, it looks like if you add
-DBDB_INDEX_USE_HASH  to your CFLAGS, it will set it back to using the Hash
based method.  FYI.

Darin Broady
dbroady@lexmark.com
Lexmark International, Inc.


|---------+------------------------------------>
|         |           Quanah Gibson-Mount      |
|         |           <quanah@stanford.edu>    |
|         |           Sent by:                 |
|         |           owner-openldap-software@O|
|         |           penLDAP.org              |
|         |                                    |
|         |                                    |
|         |           03/04/2004 12:53 PM      |
|         |                                    |
|---------+------------------------------------>
  >------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                  |
  |       To:       openldap-software@OpenLDAP.org                                                                   |
  |       cc:                                                                                                        |
  |       Subject:  Stanford moves to OL 2.2.6 for production                                                        |
  >------------------------------------------------------------------------------------------------------------------|




Since people are asking about this --

I started pushing OL 2.2.6 out to our production servers after having
tested 2.2 for the last couple of months.

For our configuration:

BDB backend
Shared memory cache instead of disk cache
slurpd replication

Note that the 2.2.6 release announcement failed to note a move from a Hash
style indices to btree style indices for BDB & HDB backends.  You can see
the effects of this migration at:

<http://www.stanford.edu/~quanah/directories/statistics/solaris/>

We will probably use HDB in the future, but there is more testing I want to
do with HDB before we make that move.  I agree completely with Frank that
syncRepl is not ready for a production environment.

I'll note that there are steps you'll want to take in upgrading from a 2.1
DB to a 2.2 DB:

1) (2.1) slapcat your database to file A
2) cat A | grep -v ^entryCSN: | grep -v ^entryUUID > B
3) (2.2) slapadd B

The format for entryCSN changed in 2.2, which can affect syncRepl whenever
it is ready.  So best to spare yourself the pain now and get those bits
rebuilt by the 2.2 slapadd.  entryUUID may or may not need to be rebuilt,
but it doesn't hurt anything to have it reconstructed.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
 GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html