Table Of Contents
Maintaining Databases
Backing Up Databases
Syntax and Location
Backup Strategy
Setting Shadow Backup Times
Performing Manual Backups
Using Third Party Backup Programs with mcdshadow
Database Recovery Strategy
Backing up and Recovering MCD Data
Checking MCD Database Integrity
Recovering MCD Data from Damaged Databases
Recovering MCD Data from Backups
MCD Recovery Errors
MCD Data Files
Backing Up CNRDB Data
Recovering CNRDB Data from Damaged Databases
Recovering CNRDB Data from Backups
Using Session Assert Commands for Data Management
Virus Scanning While Running Network Registrar
Troubleshooting Databases
Using the cnr_exim Data Import and Export Tool
Using the mcdadmin Tool
Using the cnrdb_recover Utility
Using the cnrdb_verify Utility
Using the cnrdb_checkpoint Utility
Using the keybuild Tool
Using the dbcheck Tool
Using the cnr_zone_recovery Tool
Using Wildcards
Usage Examples
Maintaining Databases
This chapter explains how to maintain the Cisco CNS Network Registrar databases.
Backing Up Databases
Because the Network Registrar database does a variety of memory caching and may be active at any time, you cannot rely on third-party system backups to protect the database. For one thing, there may be Network Registrar operations in progress during the backup, causing backup data inconsistency and an unusable replacement database.
For this purpose, Network Registrar provides a shadow backup utility, mcdshadow. Once a day, at a configurable time, Network Registrar suspends all activity to the database and takes a snapshot of the critical files. This snapshot is guaranteed to be a consistent view of the database. The mcdshadow program backs up the DNS data even when you run the shadow backup on a secondary server. This backup is only a single generation backup.
Syntax and Location
Before undertaking a database backup or recovery, be sure to understand that the notation ".../data/db" in the following sections refers to directories in the Network Registrar product installation path, depending on the operating system:
•
Windows—".../data/db" means the data directory in the installation path, which by default is \Program Files\Network Registrar\Local | Regional\data\db.
•Solaris and Linux—".../data/db" means the data directory in the installation path, which by default is /var/nwreg2/local | regional/data/db.
Network Registrar database utility programs mentioned in the following sections are located in the ".../bin" directory, which you run as its full path name:
•Windows—".../bin/program" means the bin directory in the installation path, which by default is \Program Files\Network Registrar\Local | Regional\bin\program, where program is the program filename.
•Solaris and Linux—".../bin/program" means the bin directory in the installation path, which by default is /opt/nwreg2/local | regional/usrbin/program, where program is the program filename.
Note Use only the approved utilities for each type of database. In Windows, if you want to run the utility from outside the installed path, you must set the CNR_HOME environment variable.
Backup Strategy
The backup strategy involves backing up three databases using the mcdshadow utility:
•MCD database—...data/db
•CNRDB and CCM database—...data/dhcp/ndb, data/dns/ndb, data/mcd/ndb, and data/ccm/ndb
•DNS zone checkpoint database—...data/dns/zchk
The most basic component of a backup strategy is the daily shadow backup. When problems occur with the operational database, you might need to try recovering based on the previous day's shadow backup. Therefore, you must recognize and correct any problems that prevent a successful backup.
The most common problem is disk space exhaustion. To get a rough estimate of disk space requirements, sum up the sizes of the following MCD and CNRDB database files:
.../data/dhcp/ndb/dhcp.ndb
.../data/dhcp/ndb/logs/log.*
.../data/dns/ndb/logs/log.*
A conservative approach is ten times the space consumed by these combined database files. System load, such as usage patterns, application mix, and the load on Network Registrar itself, may dictate that a much larger reserve of space be available.
You should regularly archive existing shadow backups (such as to tape, other disks, or other systems) to preserve them for possible future recovery purposes.
Caution There are different database technologies Network Registrar uses with distinct sets of utility programs, as described in the following sections. Using a utility on the wrong type of database can cause database corruption. Use only the utilities indicated. Also, never use the database utilities on the operational database, only on a copy.
Setting Shadow Backup Times
You can set the time at which an automatic shadow backup should occur in the cnr.conf file, which is located in .../conf. Edit the file and change the cnr.backup-time variable to the hour and minute of the automatic shadow backup, in 24-hour HH:MM format. For example, the following is the default:
Performing Manual Backups
You can also initiate a manual shadow backup with the mcdshadow utility.
Caution Stop all Network Registrar processes before you use the
mcdshadow backup utility.
Enter the mcdshadow command at the command prompt to perform the shadow backup. Because a full copy of the database is created, the backup may take a few minutes.
Using Third Party Backup Programs with mcdshadow
You should avoid scheduling third party backup programs while mcdshadow is operating, with a margin of an hour in either direction. As described in the "Setting Shadow Backup Times" section, the default shadow backup time is daily at 23:45.
Caution Configure third party backup programs to skip the Network Registrar operational database directories and files, and to back up only their shadow copies. Otherwise, your server might crash. The operational files are listed in the
"Backup Strategy" section. The shadow copies that you can back up are the db.bak, dhcp.bak, dns.bak, mcd.bak, and ccm.bak files in the .../data directory.
Network Registrar also maintains lock files in the .../tmp directory on Solaris and Linux, and the ...\temp directory on Windows. They are recreated during reboot, but are vital while a system is running. Any maintenance process (such as virus scanning and archiving) should exclude this temporary directory, together with the operational database directories and files.
Database Recovery Strategy
The database recovery strategy involves manually restoring up to four Network Registrar databases using tools specific to each type of database. This is different from the backup procedure in which one mechanism backs up all the server data. The two database types are called MCD and CNRDB. The four databases are:
•MCD Configuration database
•Central Configuration Management (CCM) MCD database
•DNS CNRDB database
•DHCP CNRDB database
The MCD database is generally used to store server configuration data. The CCM MCD database is used to store centrally managed data for the cluster. The DNS and DHCP CNRDB databases store state data for the DNS and DHCP servers.
Depending on what occurred with the database recovery event, you may need to apply one of the following options to all or just one of the databases:
•Restore the integrity of one or more of the current database files—For example, if a primary server has a hard disk failure and the Network Registrar data resides on a secondary disk, you can repair the current configuration and state databases once the system is back on line.
•Restore one or more backed up databases—For example, a server may have a hard disk failure and the Network Registrar data resides on a second disk. If you can repair two of the three existing databases, you can restore the third from backup.
•Restore backed up system configuration and state databases—For example, if a system hard disk crashes and the Network Registrar database was on that disk, you can restore the database from a backup copy.
Each of the recovery options follows the same general approach. First, stop the Network Registrar server agent. Then, restore or repair the data. Finally, restart the server agent and monitor the server for errors.
After you are sure that you executed a successful database recovery, always manually execute the mcdshadow utility to make a backup of the current configuration and state.
Backing up and Recovering MCD Data
The operational database that the mcdshadow utility uses is in .../data/db and the shadow copy is in .../data/db.bak. The actual file names are mcddb.d01, mcddb.d02, and mcddb.d03.
The mcdshadow utility generates an SNMP trap if it finds inadequate disk space for the backup, provided that the trap is configured.
Caution For the MCD database, use only the
dbcheck and
keybuild utilities. Do not use the cnrdb_archive, cnrdb_recover, or cnrdb_verify utility that applies to the CNRDB database. See the
"Troubleshooting Databases" section for details. The
dbcheck utility encounters errors if you try to check the databases while the servers are running. You must stop the servers before you run the utility.
Checking MCD Database Integrity
You can use the dbcheck utility to check the integrity of the MCD database. Stop all Network Registrar servers. Go to the .../data/db directory for the MCD database. As a safety check, enter the command .../bin/dbcheck -a mcddb. This requires system administrator or root privileges.
Recovering MCD Data from Damaged Databases
Depending on the event that caused the database corruption, you can restore the database to a healthy state using the current data. Here are the steps:
Step 1 Stop the Network Registrar Server Agent.
Step 2 Change to the .../data/db directory.
Step 3 Rebuild the key files by entering the command .../bin/keybuild mcddb.
Step 4 As a safety check, enter the command .../bin/dbcheck mcddb. This requires system administrator or root privileges.
Remember to stop the servers first. If there are any indications that the database recovery was unsuccessful, restore the database from a backup, as described in the "Recovering MCD Data from Backups" section. Also see the "MCD Recovery Errors" section.
Recovering MCD Data from Backups
Use the shadow backup to recover MCD data, either because a system crash corrupted the regular working database or the disk on which it resides is corrupted.
Step 1 Stop the Network Registrar Server Agent. Be sure that enough disk space is available for two copies of the database files, plus a 15% safety margin.
Step 2 Ensure that the following three files are in .../data/db.bak:
•mcddb.d01
•mcddb.d02
•mcddb.d03.
Step 3 Copy these files to .../data/db. Do not use the move command, because you may need these files again. You do not need to delete the current contents of the .../data/db directory, as these files are cleaned up automatically.
Step 4 Change to the .../data/db directory.
Step 5 To rebuild the key files, enter the command .../bin/keybuild mcddb.
Step 6 As a safety check, enter the command .../bin/dbcheck mcddb. This requires system administrator or root privileges.
Caution The CCM CNRDB database maintains centrally managed configuration data that is synchronized with the server configuration data. After restoring from backup, be sure to also restore the CCM CNRDB database from the same backup to maintain a consistent use of your configuration data.
MCD Recovery Errors
You should not have errors. If you do, ensure that:
•The Network Registrar Server Agent is stopped.
•Your current working directory is .../data/db directory.
•The mcddb.dbd and mcdschema.txt files are present in the .../data/db directory. If the files are lost or corrupted, backup files are stored in the .../data/db.bak directory.
MCD Data Files
You need the files listed in Table 7-1 for a fully functioning MCD database. As described earlier, only a subset of these files are present in a shadow backup. You need at a minimum the mcddb.dbd, mcddb.d0x, and mcdschema.txt files to rebuild the database from a backup.
Table 7-1 MCD Data Files in .../data/db Directory
Data File
|
Description
|
mcddb.dbd
|
Template file that describes the low level data schema for the MCD runtime library. Network Registrar cannot run without this file.
|
mcddb.k01-k03
|
Key files that contain the redundant data—Network Registrar does not back up these files because they can be completely rebuilt with the keybuild command.
|
mcddb.d01-d03
|
MCD data repository files.
|
mcdConfig.txt
|
Text file from which Network Registrar configures the initial install time database.
|
mcdschema.txt
|
Text file containing a version number of the schema in the mcddb.dbd file. Network Registrar does not try to open the database unless the number in this file matches a version constant in the libraries. Network Registrar cannot run without this file.
|
vista.taf, tcf, tjf
|
Working files MCD runtime uses to ensure transactional integrity. When database files are restored from a backup, the server uses or discards these files as needed.
|
Backing Up CNRDB Data
In the case of the CNRDB databases, the mcdshadow utility copies the database and all log files to a secondary directory in the directory tree of the installed Network Registrar product. For:
•DHCP—The operational database is in the .../data/dhcp/ndb directory and the associated operational logs are in the .../data/dhcp/ndb/logs directory. The database shadow copy is in the .../data/dhcp.bak/ndb directory and the associated log copy is in the .../data/dhcp.bak/ndb/logs directory.
•DNS—The operational database is in the .../data/dns/ndb directory. The important operational components are the changeset database and zone checkpoint files. The changeset database is in the .../data/dns/ndb/dns.ndb file, and its associated log files are in the .../data/dns/ndb/logs directory. The zone checkpoint files are in the .../data/dns/zchk directory. The shadow copies are in the .../data/dns.bak directory.
•CCM—The operational database and associated log files are in the .../data/ccm/ndb directory. The shadow copies are in the .../data/ccm.bak directory.
•MCD—the operational database and associated log files are in the .../data/mcd/ndb directory. The shadow copies are in the .../data/mcd.bak directory.
The actual file naming convention is:
•Database—dhcp.ndb and dns.ndb.
•Log files—log.0000000001 through log.9999999999. Typically only a small number of log files are present on a system. The specific file name extensions in use at a site vary over time as the database is used. These files are not humanly readable.
Recovering CNRDB Data from Damaged Databases
Depending on the event that caused the database corruption, you can restore the database to a healthy state using the current data. This is the best option. Always attempt recovery on a copy of the database file and associated log files, never on the operational files. This is a simple file copy operation, distinct from a shadow backup. Also, never attempt a recovery while Network Registrar is running.
Caution It is possible to damage the CNRDB database files without the damage being immediately obvious. Such damage could occur because of (a) inappropriately deleting log files; (b) mixing pre- and postrecovery database and log files; (c) attempting recovery of database files currently in use by an application; or (d) using tools intended for other databases, such as MCD database tools. For the CNRDB database, be sure to use only the
cnrdb_archive,
cnrdb_recover, and
cnrdb_verify utilities. Do not use the
keybuild and
dbcheck utilities that apply to the MCD database.
Use the cnrdb_recover utility, included in the Network Registrar product distribution, for database recovery. Use this tool with care. You should never use it directly on an operational database, or on files another application is concurrently accessing. On a successful database recovery, do not intermingle the recovered files (database file and log files) with files from another source, such as the operational database or shadow backups. Recovered database files acquire state information that make them incompatible with older database files.
Here is the procedure for CNRDB database recovery:
Step 1 Stop the Network Registrar server agent. This stops all the protocol servers. Ensure that enough disk space is available for two copies of the database files, plus a 15% safety margin.
Step 2 Create two temporary directories, dbcopy and recover, outside the Network Registrar installation tree, for safety. On Windows, these might be C:\temp\dbcopy and C:\temp\recover. On Solaris and Linux, these might be /tmp/dbcopy and /tmp/recover.
Step 3 Copy the database files using shell copy commands, in the following order:
a. Copy the CNRDB operational database file to subdirectories of .../dbcopy/. For:
•DHCP—.../data/dhcp/ndb/dhcp.ndb file to .../dbcopy/dhcp/
•DNS—.../data/dns/ndb/dns.ndb file to .../dbcopy/dns/
•CCM—.../data/ccm/ndb/*.db files to .../dbcopy/ccm/
•MCD—.../data/mcd/ndb/*.db files to .../dbcopy/mcd/
b. Copy the associated log files to subdirectories of .../dbcopy/. For:
•DHCP—.../data/dhcp/ndb/logs/log.* files to .../dbcopy/dhcp
•DNS—.../data/dns/ndb/logs/log.* files to .../dbcopy/dns
•CCM—.../data/ccm/ndb/logs/log.* files to .../dbcopy/ccm/
•MCD—.../data/mcd/ndb/logs/log.* files to .../dbcopy/mcd/
c. Double-check that the database file and all log files were copied correctly. The .../dbcopy area contains a safety copy of the database files. Do not allow these files to be modified in any way. Do not run any utilities or servers on these files.
Step 4 Copy the same operational database files as in the last step again, but this time to subdirectories of the .../recover directory:
•DHCP database—.../data/dhcp/ndb/dhcp.ndb file to .../recover/dhcp/
•DNS database—.../data/dns/ndb/dns.ndb file to .../recover/dns/
•CCM database—.../data/ccm/ndb/*.db files to .../recover/ccm/
•MCD database—.../data/mcd/ndb/*.db files to .../recover/mcd/
•DHCP log—.../data/dhcp/ndb/logs/log.* files to .../recover/dhcp
•DNS log—.../data/dns/ndb/logs/log.* files to .../recover/dns
•CCM log—.../data/ccm/ndb/logs/log.* files to .../recover/ccm/
•MCD log—.../data/mcd/ndb/logs/log.* files to .../recover/mcd/
Step 5 Try to recover the current database files:
a. Change to the appropriate subdirectory of .../recover and run the recovery utility program, cnrdb_recover -c -v. It is helpful to use the -v option; otherwise, the utility displays no output in the absence of errors. For details on this utility and its further options, see the "Using the cnrdb_recover Utility" section.
b. Run the verification utility program for each of the servers. There is no output if the verification was successful. For details on the cnrdb_verify utility and its options, see the "Using the cnrdb_verify Utility" section. For:
•DHCP—cnrdb_verify dhcp.ndb in .../recover/dhcp
•DNS—cnrdb_verify dns.ndb in .../recover/dns
•CCM—cnrdb_verify each *.db file in .../recover/ccm
•MCD—cnrdb_verify each *.db file in .../recover/mcd
c. Optionally, for additional confidence, run the cnrdb_archive utility program from the .../recover directory:
•cnrdb_archive -l—lists all log files
•cnrdb_archive -s—lists the database file
d. If there are any indications that an error occurred, proceed to restore the database from a backup, as described in the "Recovering CNRDB Data from Backups" section.
e. Replace the operational database file and log files in the Network Registrar installation tree with the files in .../recover. Be careful not to mix database files processed with cnrdb_recover with those that were not. To avoid this problem, delete the operational CNRDB file and log files from the Network Registrar installation. In copying the recovered files, ensure that the database file and log files are copied to the appropriate and separate directories in the Network Registrar installation tree:
•DHCP database—.../recover/dhcp/dhcp.ndb file to .../data/dhcp/ndb/
•DNS database—.../recover/dns/dns.ndb file to .../data/dns/ndb/
•CCM database—.../recover/ccm/*.db files to .../data/ccm/ndb/
•MCD database—.../recover/mcd/*.db files to .../data/mcd/ndb/
•DHCP log—.../recover/dhcplog.* files to .../data/dhcp/ndb/logs/
•DNS log—.../recover/dnslog.* files to .../data/dns/ndb/logs/
•CCM log—.../recover/ccm/log.* files to .../data/ccm/ndb/logs/
•MCD log—.../recover/mcd/log.* files to .../data/mcd/ndb/logs/
f. Delete the files in the .../data/dhcpeventstore directory.
g. Restart Network Registrar.
Recovering CNRDB Data from Backups
If there are any indications, such as server log messages or missing data, that database recovery was unsuccessful, you may need to base a recovery attempt on the current shadow backup (in the Network Registrar installation tree).
The procedure (as follows) is identical to that of Step 5 in the previous section, except that the current contents of .../dbcopy/ are not disturbed, and the source of the files copied to .../recover is .../data/dhcp.bak, .../data/dns.bak, or .../data/ccm.bak.
Step 1 Once the files from the shadow backup are copied to .../recover, copy the operational log files from .../data/dhcp/ndb/logs, .../data/dns/ndb/logs, or .../data/ccm/ndb/log.* to .../recover. This may cause older files in.../recover to be overwritten by newer log files from the operational database. This is expected and typically occurs to at least one log file. Be careful, however, not to do the reverse by overwriting new log files from the operational database with older ones from the shadow backup.
If the cnrdb_recover operation fails, try it again, this time using only the shadow backup files and not copying the operational log files. In this case, all data written to the database since the shadow backup was made is lost.
Step 2 If this fails, perhaps because the current shadow backup is simply a copy of corrupted files, use the most recent previous shadow backup. (This illustrates the need to regularly archive shadow backups.) You cannot add operational log files to older shadow backup files. All data added to the database since the shadow backup was made will be lost.
Step 3 After a successful database recovery:
a. As a safety measure, archive the contents of .../dbcopy/.
b. Using the mcdshadow utility, initiate an immediate shadow backup and archive the files. See the "Performing Manual Backups" section. This backup is the earliest, oldest backup from which you can attempt a future recovery. You cannot use older shadow backups.
Caution The CCM CNRDB database maintains centrally managed configuration data that is synchronized with the server configuration databases. If you restore the CCM CNRDB files from backup, also restore the MCD database from the same backup.
Using Session Assert Commands for Data Management
You can use the CLI session assert commands to simplify interactions with external data management processes. It also helps in writing multicommand batch scripts that stop processing if an asserted precondition fails. You generally use these commands with the default session format of script. If the assertion passes, you get a "100 Ok" message. If it fails, you get a "107 Assertion Failed xxx.dbsn (minor-serial-number) = value" message and the CLI exits.
The session assert locked command exits the CLI if it cannot lock the session. This sample command file performs batch operations requiring a lock:
session set default-format=script
commands-that-require-a-lock
The session assert dhcp.dbsn command exits the CLI session if the minor serial number of the DHCP server does not match (==) or does not exceed (!=) the value given. The minor serial number is incremented with each configuration change. Get its value using the dhcp get dbsn command. This sample script modifies a DHCP server based on configuration version 1234:
session set default-format=script
session assert dhcp.dbsn == 1234
scope scope1 create 192.168.1.0 255.255.255.0
scope scope1 addRange 192.168.1.10 192.168.1.200
This sample script lists DHCP configuration changes made since version 1234:
session set default-format=script
session assert dhcp.dbsn != 1234
Virus Scanning While Running Network Registrar
If you have virus scanning enabled on your system, it is best to configure it to exclude certain Network Registrar directories from being scanned. Including these directories might impede Network Registrar operation. Exclude from scanning the following directories and their subdirectories:
•.../data
•.../logs
•.../temp
Troubleshooting Databases
The following sections describe troubleshooting the Network Registrar databases.
Using the cnr_exim Data Import and Export Tool
Because Network Registrar extends the data repositories to serve the Web UI, the current Network Registrar data import and export tool, mcdadmin, is no longer adequate (see the "Using the mcdadmin Tool" section). The cnr_exim data import and export tool now serves to import data to and export data from Network Registrar servers. The cnr_exim tool overcomes the mcdadmin limitations of not being able to export dynamic resource record information.
Before using the cnr_exim tool, exit from the CLI. Then, find the tool on:
•Windows—...\bin\cnr_exim.exe
•Solaris and Linux—.../usrbin/cnr_exim
You must reload the server for the imported data to become active.
Note that text exports are reading purposes only. You cannot re-import them.
The data export syntax is:
> cnr_exim -e exportfile [-N username -P password -C cluster]
(The username and password are prompted for if omitted. The cluster defaults to the local cluster.)
To export raw data, use the -x option:
> cnr_exim -e exportfile -x
To get a complete configuration export you should also export dynamic resource records by including the -a dynRR option; to export them alone without any other components, add the -c "none" option:
> cnr_exim -e exportfile -a dynRR -c "none"
To export DNS server and zone components as binary data in raw format, use the -x and -c options:
> cnr_exim -e exportfile -x -c "dnsserver,zone"
The data import syntax is:
> cnr_exim -i importfile [-N username -P password -C cluster]
The import file must be in raw format.
You can also overwrite existing data with the -o option:
> cnr_exim -i importfile -o
When you import a configuration including dynamic resource records (either into a new system or overwriting data in the current system), you must import in two steps to get the complete configuration:
1. Do a standard import using cnr_exim -i. This imports all but the dynamic resource records. Then, reload the DNS server so that server picks up zone configuration data and allows it to accept dynamic resource records.
2. Import just the dynamic resource records with the command:
> cnr_exim -i importfile -a dynRR -c "none"
Table 7-2 describes all the qualifying options for the cnr_exim tool.
Table 7-2 cnr_exim Options
Option
|
Description
|
-a dynRR
|
Imports or exports dynamic resource records only. It assumes that the DNS server was reloaded and zone data exists. (You can combine this option with the
-c "none" option to import or export dynamic resource records only.)
|
-c "components"
|
Imports or exports Network Registrar components, as a quoted, comma-delimited string. Use -c help to view the supported components. User names are not exported by default; you must explicitly export them using this option, and they are always grouped with their defined groups and roles. Secrets are never exported.
Note After you import administrator names, you must set new passwords for them. If you export groups and roles separately from user names (which are not exported by default), their relationship to user names is lost.
|
-C cluster
|
Imports from or exports to the specified cluster. Defaults to localhost.
|
-e exportfile
|
Exports the configuration to the specified file.
|
-h
|
Displays help text for the supported options.
|
-i importfile
|
Imports the configuration to the specified file. The import file must be in raw format.
|
-N username
|
Imports or exports using the specified username.
|
-o
|
When used with the -i (import) option, overwrites existing data.
|
-P password
|
Imports or exports using the specified password.
|
-x
|
When used with the -e (export) option, exports binary data in raw format.
|
Using the mcdadmin Tool
The mcdadmin tool is a utility with which you can import and export the MCD database and diagnose Network Registrar conditions under Cisco guidance. This tool is relevant for versions of Network Registrar before Release 6.0 only.
Caution Use this tool only under the guidance of the Cisco Technical Assistance Center. Casual use can inflict catastrophic damage to the Network Registrar configuration database. This tool is only relevant for versions of Network Registrar before Release 6.0. For Network Registrar Release 6.0 data imports and exports, see the
"Using the cnr_exim Data Import and Export Tool" section.
Before using the mcdadmin tool, exit from the CLI. Then, find the tool on:
•Windows—...\bin\mcdamin.exe
•Solaris and Linux—.../usrbin/mcdadmin
Run the tool from the command shell. This example displays the application version number:
This command overwrites the current configuration database with the installation defaults:
> mcdadmin -i cnrconfig.txt -z m=3
This command exports the scopePC scope configuration data to the cnrconfig.txt file:
> mcdadmin -e cnrconfig.txt -p /servers/name/dhcp/1/scopes/scopePC/ -x -z m=3
Table 7-3 describes the qualifying options. The absolute path to an object in the MCD tree, dbpath, always begins and ends with a forward slash (/).
Table 7-3 mcdadmin Options
Option
|
Description
|
-a area
|
Specifies the area of the database to use: config (the default), state, altconfig, or altstate.
|
-c
|
Creates the MCD database, and deletes your existing one.
Note Use this option only under Cisco Technical Assistance Center guidance.
|
-d dbname
|
Specifies the database name or the default database.
|
-e exportfile
|
Exports the configuration to the specified file, or a dash (-) for standard output.
> mcdadmin -N admin -P changeme -e mcdconfig.txt
> mcdadmin -N admin -P changeme -e -
|
-G gen
|
When used with the -e (export) option, specifies the generation number for the resource record table export.
|
-H
|
Dumps the full table generational history.
|
-i importfile
|
Imports the configuration from the specified file, or a dash (-) for standard input.
> mcdadmin -N admin -P changeme -o -i mcdconfig.txt -z m=3
Note If used with -o, -i overwrites the current database. If not used with -o, creates new the entries introduced by the file.
|
-k
|
When used just by itself, kills the lock manager.
|
-l
|
When used with the -i (import) option, hold an exclusive lock while importing.
|
-o
|
Overwrites the contents of the current database with entries of the same name.
|
-O
|
Merges the data into the existing database, while ignoring unique keys and the resource record tables.
|
-p dbpath
|
When used with the -e (export) option, specifies the subset of the configuration database to export, as an absolute path.
> mcdadmin -N admin -P changeme -e scopepc.txt
-p /servers/name/dhcp/1/scopes/scopePC/ -x -z m=3
|
-r dbpath
|
Removes the specified path in the MCD database, not including subentries.
> mcdadmin -r /servers/name/dhcp/1/scopes/scopePC/
|
-R dbpath
|
Recursively removes all entries below and including the specified path.
Note Using this option can destroy large portions of the MCD database that may require partial or total reconstruction
|
dbpath
|
The use of dbpath in -p, -r, and -R is either an absolute path name starting with /, when it refers to that part of the MCD tree, or a server zone name tuple, starting with a colon (:). The fields after the colon are whitespace-separated and the name, or zone and name, can be left unspecified. For example, -p ":myserv example.com. mypath".
|
-t dir
|
Specifies the directory from which to get the database templates.
|
-T
|
Recopies the database templates when creating the database.
|
-v or -V
|
Prints version information.
|
-x
|
When used with the -e (export) option, exports binary data in raw format.
> mcdadmin -N admin -P changeme -e mcdconfig.txt -x
|
-z class=n
|
Sets the debugging class or classes to level n.
> mcdadmin -N admin -P changeme -c -o -i mcdconfig.txt -z m=3
|
Using the cnrdb_recover Utility
The cnrdb_recover utility is useful in restoring the Network Registrar databases to a consistent state after a system failure. You would typically use the -c and -v options with this command (Table 7-4 describes all of the qualifying options). The utility is located in the installation bin directory.
Table 7-4 cnrdb_recover Options
Option
|
Description
|
-c
|
Performs a catastrophic recovery instead of a normal recovery. It not only examines all the log files present, but also recreates the .ndb (or .db) file in the current or specified directory if the file is missing, or updates it if is present.
|
-e
|
Retains the environment after running recovery, rarely used unless there is a db_config file in the home directory.
|
-h dir
|
Specifies a home directory for the database environment. By default, the current working directory is used.
|
-t
|
Recovers to the time specified rather than to the most current possible date. The time format is [[CC]YY]MMDDhhmm[.ss] (the brackets indicating optional entries, with the omitted year defaulting to the current year).
|
-v
|
Runs in verbose mode.
|
-V
|
Writes the library version number to the standard output, and exits.
|
In the case of a catastrophic failure, restore a snapshot of all database files, along with all log files written since the snapshot. If not catastrophic, all you need are the system files at the time of failure. If any log files are missing, cnrdb_recover -c identifies the missing ones and fails, in which case you need to restore them and perform the recovery again.
This example shows possible output from this utility:
C:\temp\recover\dns> "C:\Program Files\Network Registrar\Local\bin\cnrdb_recover" -c -v
db_recover:Finding last valid log LSN:file:1 offset 83482
db_recover:Recovery starting from [0][0]
db_recover:Recovery complete at Thu Jul 25 21:18:58 2002
db_recover:Maximum transaction ID 80000013 Recovery checkpoint [1][83770]
db_recover:Recovery complete at Thu Jul 25 21:18:58 2002
db_recover:Maximum transaction id 80000000 Recovery checkpoint [1][83770]
If you forget to copy the log files into the directory, the output might look like this (note that the maximum transaction ID was not incremented):
C:\temp\recover\dns> "C:\Program Files\Network Registrar\Local\bin\cnrdb_recover" -c -v
db_recover:Recovery complete at Thu Jul 25 21:19:20 2002
db_recover:Maximum transaction id 80000000 Recovery checkpoint [0][0]
Using the cnrdb_verify Utility
The cnrdb_verify utility is useful for verifying the structure of the Network Registrar databases. The command requires a file parameter. Use this utility only if you are sure there are no programs running that are modifying the file. Table 7-5 describes all its qualifying options. The utility is located in the installation bin directory.
Table 7-5 cnrdb_verify Options
Option
|
Description
|
-h dir
|
Specifies a home directory for the database environment. By default, the current working directory is used.
|
-N
|
Prevents acquiring shared region locks while running, intended for debugging errors only, and should not be used under any other circumstances.
|
-q
|
Suppresses printing any error descriptions other than exit success or failure.
|
-V
|
Writes the library version number to the standard output, and exits.
|
Using the cnrdb_checkpoint Utility
The cnrdb_checkpoint utility is useful in setting a checkpoint for the database files so as to keep them current. The utility is located in the installation bin directory. The syntax is described in the usage information when you run the command:
C:\Program Files\Network Registrar\Local\bin>cnrdb_checkpoint ?
usage: db_checkpoint [-1Vv] [-h home] [-k kbytes] [-L file] [-p min]
Using the keybuild Tool
The keybuild tool is a utility you can use to rebuild the database key files, which contain redundant data with the MCD files:
•On Windows—Click Start > Settings > Control Panel > Administrative Tools > Services, highlight Network Registrar Local Server Agent or Network Registrar Regional Server Agent, then click Stop. You need system administrator privileges. Go to the install-location\data\db folder and run the keybuild.exe file:
•On Solaris—Stop the Server Agent. Go to the .../data/db folder. You need root privileges:
/etc/init.d/nwreglocal stop
/etc/init.d/nwregregion stop
Using the dbcheck Tool
The dbcheck tool is a utility you can use to check the MCD integrity. You must have system administrator or root privileges to run the dbcheck tool:
•On Windows—Click Start > Settings > Control Panel > Administrative Tools > Services, highlight Network Registrar Local Server Agent or Network Registrar Regional Server Agent, click Start, then go to the ...\data\db folder and run the dbcheck.exe file:
•On Solaris and Linux—Stop the server agent, then go to the .../data/db folder and run the dbcheck file:
/etc/init.d/nwreglocal stop
/etc/init.d/nwregregion stop
Caution Do not run the
dbcheck utility while the servers are running.
Using the cnr_zone_recovery Tool
The cnr_zone_recovery tool is used to convert a secondary zone into a primary zone when the primary zone is lost for some reason. It provides a flexible mechanism to describe the zone configuration and then uses that description to recreate a primary server that is as close as possible to the original.
Before using cnr_zone_recovery, exit from the CLI. Then, find the tool on:
•Windows—...\bin\cnr_zone_recovery.exe
•Solaris and Linux—.../usrbin/cnr_zone_recovery
Run the tool from the command shell. This example prints help on the command options:
Note If the source and destination clusters are the same, both specifications should be the hostname or both the IP address. Otherwise, the tool does not prompt to overwrite the existing zones.
Table 7-6 describes the qualifying options for the cnr_zone_recovery tool. For an explanation of using wildcards, see the "Using Wildcards" section.
Table 7-6 cnr_zone_recovery Options
Option
|
Description
|
-b zonecount
|
Number of zones to process at a time. Note that two DNS reloads are performed per matching zone. The default is one zone.
|
-d static | dynamic
|
Determines if unmapped RRsets should be static or dynamic.
|
-h
|
Provides help on command options.
|
-i serial-bump
|
Amount by which to bump the serial number. Defaults to 100.
|
-l on | off
|
Turns logging on or off (the default is on). Creates a zone_recover_log file in the /logs directory (that is accessibly only by the root user in Solaris and Linux). If set to off, only errors and statistics are logged.
|
-m file
|
File containing a comma-separated string list for zone filtering. To exclude a zone or zone name pattern, append the string :x to the name or pattern. List excluded zones before included ones. When using zone filtering, any zones that do not match the filter list are ignored. Wildcards are allowed.
|
-n list
|
Quoted, comma-separated string list for zone filtering. To exclude a zone or zone name pattern, append the string :x to the name or pattern (see the -m option for an example). Wildcards are allowed. For example:
> cnr_zone_recovery -n "example.com:x"
|
-N username
|
Default username (if not specified) for all clusters.
|
-p cluster[:port][/username/password]
|
Primary cluster and optional port, username and password containing the primary zones. Required if not using the -s option. The cluster can be a hostname or IP address. The default port is 1234. If the /username/password is omitted, you are prompted for their entry, unless you also use the -N and -P options.
|
-P password
|
Default password (if not specified) for all clusters.
|
-q file
|
File containing a comma-separated string list with each element followed by a colon and s for static or d for dynamic. Wildcards are allowed.
|
-r list
|
Quoted, comma-separated string list with each element followed by a colon and s for static or d for dynamic. Wildcards are allowed.
|
-s cluster[:port][/username/password]
|
Secondary cluster and optional port, username and password containing the primary zones. Required if -p is omitted. The cluster can be a hostname or IP address. The default port is 1234. If the /username/password is omitted, you are prompted for their entry, unless you also use the -N and -P options.
|
-t cluster[:port][/username/password]
|
Target cluster and optional port, username and password containing the primary zones. The default target cluster is the local host cluster. The cluster can be a hostname or IP address. The default port is 1234. If the /username/password is omitted, you are prompted for their entry, unless you also use the -N and -P options.
|
-u
|
Run in update mode and do not overwrite existing data.
|
-v
|
Gets the software version of the tool.
|
-z
|
Sets the DTRACE level for debugging. The valid DTRACE levels are:
•X=1 for error messages
•X=2 for warning messages
•X=3 for informational messages
•X=9 for debugging information
|
Using Wildcards
The filtering mechanism for the cnr_zone_recovery tool provides wildcards:
•* matches zero or more characters. For example, the pattern dhcp-* matches all strings with the dhcp- prefix, including the string dhcp-.
•? matches a single character. For example, the pattern zone?.com matches zone1.com, zone2.com, and so on, but does not match zone.com.
•[xy] matches any characters (or a range such as 0-9 or a-z) listed in the brackets. If the pattern should include a hyphen (-), make it the first character in the list (such as dhcp[-a-z]*).
Usage Examples
Examples of usage of the cnr_zone_recovery tool include:
•Specifying a secondary source and target:
> ./cnr_zone_recover -s source-cluster -t target-cluster
•Specifying a username and password on the command line:
> ./cnr_zone_recover -s source-cluster/admin/changeme -t target-cluster/admin/changeme
•Using RRset filtering on the command line:
> ./cnr_zone_recover -s source-cluster -t target-cluster -r "dhcp-*:d,www:s"
•Using RRset filtering by specifying a file:
> ./cnr_zone_recover -s source-cluster -t target-cluster -q rrset-file.txt
Sample contents of the rrset-file.txt file:
•Using zone filtering on the command line (listing the excluded zone first):
> ./cnr_zone_recover -s source-cluster -t target-cluster -n "example.com:x,*.com"
•Using zone filtering by specifying a file:
> ./cnr_zone_recover -s source-cluster -t target-cluster -m zone-file.txt
Sample contents of the zone-file.txt file (listing the excluded zone first):
•Changing the RRset default category to static:
> ./cnr_zone_recover -s source-cluster -t target-cluster -d static
•Choosing not to overwrite existing data:
> ./cnr_zone_recover -s source-cluster -t target-cluster -u
Feedback
