Module: sip-router
Branch: janakj/bdb
Commit: 12dc32352537f93ca8e94a0afbfd802125316a1b
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=12dc323…
Author: Klaus Darilion <klaus.darilion(a)pernau.at>
Committer: Klaus Darilion <klaus.darilion(a)pernau.at>
Date: Wed Aug 6 11:44:43 2008 +0000
- renamed: bdb_recover -> kambdb_recover
git-svn-id:
https://openser.svn.sourceforge.net/svnroot/openser/trunk@4602
689a6050-402a-0410-94f2-e92a70836424
---
modules/db_berkeley/km_README | 26 +++++++++++-----------
modules/db_berkeley/km_doc/db_berkeley_admin.xml | 22 +++++++++---------
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/modules/db_berkeley/km_README b/modules/db_berkeley/km_README
index 694489e..f2dd471 100644
--- a/modules/db_berkeley/km_README
+++ b/modules/db_berkeley/km_README
@@ -43,7 +43,7 @@ Will Quan
1.10. METADATA_READONLY (optional)
1.11. METADATA_LOGFLAGS (optional)
1.12. DB Maintaince Script : kamdbctl
- 1.13. DB Recovery : bdb_recover
+ 1.13. DB Recovery : kambdb_recover
1.14. Known Limitations
List of Examples
@@ -57,7 +57,7 @@ Will Quan
1.7. METADATA_KEYS
1.8. METADATA_LOGFLAGS
1.9. kamdbctl
- 1.10. bdb_recover usage
+ 1.10. kambdb_recover usage
Chapter 1. Admin Guide
@@ -101,7 +101,7 @@ modparam("db_berkeley", "auto_reload", 1)
The following operations can be journaled: INSERT, UPDATE,
DELETE. Other operations such as SELECT, do not. This
journaling are required if you need to recover from a corrupt
- DB file. That is, bdb_recover requires these to rebuild the db
+ DB file. That is, kambdb_recover requires these to rebuild the db
file. If you find this log feature useful, you may also be
interested in the METADATA_LOGFLAGS bitfield that each table
has. It will allow you to control which operations to journal,
@@ -203,7 +203,7 @@ modparam("db_berkeley", "journal_roll_interval",
3600)
'/usr/local/share/kamailio/db_berkeley/openser' By default
these tables are created Read/Write and without any
journalling as shown. These settings can be modified on a per
- table basis. Note: If you plan to use bdb_recover, you must
+ table basis. Note: If you plan to use kambdb_recover, you must
change the LOGFLAGS.
METADATA_READONLY
0
@@ -423,13 +423,13 @@ ce of db; output DB_PATH/db.new)
kamdbctl bdb newappend db datafile (appends data to a new instan
ce of db; output DB_PATH/db.new)
-1.13. DB Recovery : bdb_recover
+1.13. DB Recovery : kambdb_recover
The db_berkeley module uses the Concurrent Data Store (CDS)
architecture. As such, no transaction or journaling is
- provided by the DB natively. The application bdb_recover is
+ provided by the DB natively. The application kambdb_recover is
specifically written to recover data from journal files that
- Kamailio creates. The bdb_recover application requires an
+ Kamailio creates. The kambdb_recover application requires an
additional text file that contains the table schema.
The schema is loaded with the '-s' option and is required for
@@ -447,20 +447,20 @@ ce of db; output DB_PATH/db.new)
The following illustrates the four operations available to the
administrator.
- Example 1.10. bdb_recover usage
-usage: ./bdb_recover -s schemadir [-h home] [-c tablename]
+ Example 1.10. kambdb_recover usage
+usage: ./kambdb_recover -s schemadir [-h home] [-c tablename]
This will create a brand new DB file with metadata.
-usage: ./bdb_recover -s schemadir [-h home] [-C all]
+usage: ./kambdb_recover -s schemadir [-h home] [-C all]
This will create all the core tables, each with metadata.
-usage: ./bdb_recover -s schemadir [-h home] [-r journal-file]
+usage: ./kambdb_recover -s schemadir [-h home] [-r journal-file]
This will rebuild a DB and populate it with operation from jour
nal-file.
The table name is embedded in the journal-file name by conventi
on.
-usage: ./bdb_recover -s schemadir [-h home] [-R lastN]
+usage: ./kambdb_recover -s schemadir [-h home] [-R lastN]
This will iterate over all core tables enumerated. If journal f
iles exist in 'home',
a new DB file will be created and populated with the data found
@@ -474,7 +474,7 @@ n
the last hours data in table location.
Important note- A corrupted DB file must be moved out of the
- way before bdb_recover is executed.
+ way before kambdb_recover is executed.
1.14. Known Limitations
diff --git a/modules/db_berkeley/km_doc/db_berkeley_admin.xml
b/modules/db_berkeley/km_doc/db_berkeley_admin.xml
index dd5acc3..410bfe8 100644
--- a/modules/db_berkeley/km_doc/db_berkeley_admin.xml
+++ b/modules/db_berkeley/km_doc/db_berkeley_admin.xml
@@ -74,7 +74,7 @@ modparam("db_berkeley", "auto_reload", 1)
The following operations can be journaled:
INSERT, UPDATE, DELETE. Other operations such as SELECT, do not.
This journaling are required if you need to recover from a corrupt
- DB file. That is, bdb_recover requires these to rebuild
+ DB file. That is, kambdb_recover requires these to rebuild
the db file. If you find this log feature useful, you may
also be interested in the METADATA_LOGFLAGS bitfield that each
table has. It will allow you to control which operations to
@@ -223,7 +223,7 @@ modparam("db_berkeley", "journal_roll_interval",
3600)
By default, the files are installed in
'/usr/local/share/kamailio/db_berkeley/openser'
By default these tables are created Read/Write and without any journalling as
shown. These settings can be modified on a per table basis.
- Note: If you plan to use bdb_recover, you must change the LOGFLAGS.
+ Note: If you plan to use kambdb_recover, you must change the LOGFLAGS.
</para>
<programlisting format="linespecific">
METADATA_READONLY
@@ -513,13 +513,13 @@ usage: kamdbctl create
</section>
<section>
- <title>DB Recovery : bdb_recover</title>
+ <title>DB Recovery : kambdb_recover</title>
<para>
The db_berkeley module uses the Concurrent Data Store (CDS) architecture.
As such, no transaction or journaling is provided by the DB natively.
- The application bdb_recover is specifically written to recover data from
+ The application kambdb_recover is specifically written to recover data from
journal files that Kamailio creates.
- The bdb_recover application requires an additional text file that contains
+ The kambdb_recover application requires an additional text file that contains
the table schema.
</para>
@@ -540,19 +540,19 @@ usage: kamdbctl create
<para>
The following illustrates the four operations available to the administrator.
<example>
- <title>bdb_recover usage</title>
+ <title>kambdb_recover usage</title>
<programlisting>
-usage: ./bdb_recover -s schemadir [-h home] [-c tablename]
+usage: ./kambdb_recover -s schemadir [-h home] [-c tablename]
This will create a brand new DB file with metadata.
-usage: ./bdb_recover -s schemadir [-h home] [-C all]
+usage: ./kambdb_recover -s schemadir [-h home] [-C all]
This will create all the core tables, each with metadata.
-usage: ./bdb_recover -s schemadir [-h home] [-r journal-file]
+usage: ./kambdb_recover -s schemadir [-h home] [-r journal-file]
This will rebuild a DB and populate it with operation from journal-file.
The table name is embedded in the journal-file name by convention.
-usage: ./bdb_recover -s schemadir [-h home] [-R lastN]
+usage: ./kambdb_recover -s schemadir [-h home] [-R lastN]
This will iterate over all core tables enumerated. If journal files exist in
'home',
a new DB file will be created and populated with the data found in the last N files.
The files are 'replayed' in chronological order (oldest to newest). This
@@ -564,7 +564,7 @@ usage: ./bdb_recover -s schemadir [-h home] [-R lastN]
</para>
<para>
- Important note- A corrupted DB file must be moved out of the way before bdb_recover is
executed.
+ Important note- A corrupted DB file must be moved out of the way before kambdb_recover
is executed.
</para>
</section>