Module: sip-router Branch: janakj/bdb Commit: 12dc32352537f93ca8e94a0afbfd802125316a1b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=12dc3235...
Author: Klaus Darilion klaus.darilion@pernau.at Committer: Klaus Darilion klaus.darilion@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>