2 Using Citadel/UX with Sleepycat (Berkeley) DB
6 [1]Citadel/UX can now use the robust and scalable [2]Berkeley DB from
7 Sleepycat Software as its data store, for increased scalability,
8 reliability, and recoverability.
10 History and introduction
12 From its inception in 1987 until versions 5.1x in 1998,
13 Citadel/UX utilized a built-in data store loosely modeled after Jeff
14 Prothero's original Citadel-CP/M design. But as Citadel systems
15 scaled upwards, supporting Internet-connected systems with heavy
16 concurrent use, and aspirations of becoming a world-class
17 messaging/groupware platform someday, the developers made the decision
18 to switch to an embedded database. The Free Software Foundation's
19 [3]GDBM product was chosen for its simple API and its free license
22 Somewhat less than trouble-free operation from 1998 through 2000,
23 however, proved that GDBM was not the best choice. Heavily utilized
24 systems experienced occasional database corruption, often resulting in
25 repeated crashes of the Citadel server. As a result, we made the
26 decision to switch to [4]Berkeley DB.
28 Berkeley DB offers [5]numerous features which help Citadel/UX to meet
29 its goals as a high-end messaging platform:
30 * Database sizes can scale to hundreds of terabytes
31 * A transaction-based logging system
34 It is clear that Berkeley DB is a better choice than GDBM for a
35 high-utilization database that requires crash recovery. Citadel/UX can
36 currently be built with either DB or GDBM as the data store; however,
37 THE USE OF GDBM IS DEPRECATED AND STRONGLY DISCOURAGED. If you are
38 bringing up a new site you should use Berkeley DB, period. If you are
39 maintaining an existing site using GDBM you should migrate it to Berkeley
40 DB as soon as possible.
43 Building Citadel/UX with DB support
45 Here are the steps required to get Citadel/UX running with Berkeley
46 DB as its back end data store.
48 1. First, you must download and build Berkeley DB itself. Citadel
49 has been developed and tested with DB 3.1.17, which can be
50 downloaded from [6]www.sleepycat.com. Follow the "[7]Building for
51 UNIX" instructions. Make sure that you run the test suite, and
52 perhaps test with some of the sample applications, before moving
55 Note that as of DB 3.1.17, DB's configure script can't check for
56 OpenBSD systems. You will need to configure DB as follows:
58 env CC='gcc -pthread -Di386' ../dist/configure [flags]
60 DB 3.3.x's configure script should not need the -Di386 flag.
62 2. Start with a clean source tree. Either unpack a fresh copy of the
63 source or do a "make distclean" before continuing.
64 3. Run the configure script: ./configure
65 (Optionally specify --with-db=DIR for whatever prefix
66 you've actually installed DB into, if you overrode DB's defaults.
67 Also specify any other configure options you need at this time.)
68 4. Run "make" and "make install-exec." Continue installing Citadel
69 as per the instructions supplied with the system.
71 Migrating an existing GDBM-based Citadel to a DB-based Citadel
73 If you have an existing system, you must export your databases,
74 rebuild Citadel with DB support, and then re-import your databases
75 into the new system. Please refer to the document "[8]How to use the
76 importer/exporter" for detailed instructions on this.
78 After you export your database, but before you re-import it, you must
79 perform the following steps:
80 1. Re-build Citadel with DB support, as described above
81 2. Remove all of the *.gdbm files from your data directory.
83 Care and feeding of your DB-powered Citadel
85 Citadel uses the transaction-based logging facility of Berkeley DB.
86 Therefore you will notice log files accumulating in your data
87 directory. These are required for automatic recovery in the event of
88 a catastrophic system failure. Log files have filenames that look
89 like "log.0000000001" whereas the normal database files have names
92 So do you have to keep these log files around forever? No, but there
93 are some rules you should follow:
94 * Don't remove a log file if it's the only log file there.
95 * If it's not listed in the output of the db_archive[9] command, it's
97 * After a successful backup (see below) log files listed by the
98 db_archive[9] command may be removed to conserve disk space, if
99 those log files were backed up.
101 You may think that it's going to keep writing to that one log file
102 forever, but don't panic; when the log file gets sufficiently large it
103 will switch over to another one. As a general rule of thumb, your
104 archival procedure should be to back up to tape every day. Berkeley DB
105 supports "hot" backups; in other words, you are permitted to back up your
106 Citadel data without having to first shut down the Citadel server, as long
107 as you copy the data files before the log files.
109 And don't worry about your system filling up with log files; the Citadel
110 server will automatically remove them when they're no longer needed.
115 1. http://uncensored.citadel.org/citadel
116 2. http://www.sleepycat.com/
117 3. http://www.gnu.org/software/gdbm/gdbm.html
118 4. http://www.sleepycat.com/
119 5. http://www.sleepycat.com/xactfeatures.html
120 6. http://www.sleepycat.com/
121 7. http://www.sleepycat.com/docs/ref/build_unix/intro.html
122 8. http://pixel.citadel.org/citadel/docs/export.html
123 9. http://www.sleepycat.com/docs/utility/db_archive.html