1.3 System Administration
From Enkive Wiki
to be written
to be written
The administration scripts are located in the scripts directory beneath $ENKIVE_HOME. Since Enkive is developed and primarily used in *nix environments, the scripts are typically written in sh/bash. We hope that users will contribute analogous scripts for other environments, specifically Windows.
For many of the scripts to work, enkive-common.sh must be edited first to describe your Enkive installation's configuration. Please see its documentation below and edit the file before attempting to use any of the other scripts.
This script sets up common configuration for the other scripts. System administrators will have to edit this file to set the details of their own Enkive configuration in order for the other scripts to work. The comments in this script are relatively straight-forward. And there is some embedded testing that takes place as well to help system administrators diagnose configuration problems.
This script is used to migrate the database from an older release to a new release. This script depends on enkive-common.sh, so be sure to read about it and edit it as described.
If you upgrade Enkive and the new version needs changes to the database, when you start Enkive you will get a log message that you need to run the migration tool. The message will look something like:
This version of Enkive (1.3) requires a migrated version of the Enkive database, which appears to be for version(s) 1.2. Please run the DB Migration tool before starting Enkive.
This script is the DB Migration tool. When you run this script, it will compare the current version of the database with the one needed and make appropriate changes.
It is mandatory that you backup your database prior to running this tool in order to recover from any unforeseen issues.
This script depends on enkive-common.sh, so be sure to read about it and edit it as described in order to enable this script to function.
MongoDB, like many databases, uses indexes to help it find and sort data quickly. Indexes, however, come at a cost to build and maintain. Their maintenance requires some disk space and a little additional processing time when adding, updating, and deleting data.
A new installation of Enkive with no email in the archive will create the necessary indexes when it first starts up. And after that, the indexes will be maintained automatically. If an index should ever be dropped however, this script can be used to rebuild it. We do not rebuild indexes automatically as it's considered a bad practice within the MongoDB community. Rebuilding an index could take hours, and if done in the foreground, would make the database inaccessible for the duration of the rebuilding process. The best practice as determined by the MongoDB community is to leave index rebuilding as a system administration task, so that the time it's done along with whether it's done in the fore- or background can be determined by a competent system administrator. That's what this script does.
Enkive Index-Related Log Messages
When Enkive starts up it will check to see that all the expected indexes are in place. If any are missing the log will contain a notice, such as the following:
2012-06-25 14:38:38,560 [main] WARN com.linuxbox.enkive - Please run Enkive's MongoDB index tool; Enkive's MongoDB is missing 2 index(es) [MongoMessageArchivingService:attachment_id_index, MongoMessageArchivingService:nested_msg_id_index]
When run the script will compare the indexes that the Enkive MongoDB has against what it believes it should have. If any indexes are missing the user (a competent system administrator, we hope) is prompted for his/her desired action. Here is an example prompt:
*** Index "attachment_id_index" does not appear to exist. Options: (c)reate index in the background (c!)reate index in the foreground (s)kip this index (r)eport on other indexes without further prompts (q)uit this program Your choice:
If the administrator enters c or c! the index will be created in the background or foreground respectively. When the index is created in the foreground, no other database activity is allowed. Depending on the amount of data that is being indexed, this process could take seconds, minutes, hours or days. Therefore, in general, creating the index in the foreground is not recommended.
When the index is built in the background, other database activities can occur in parallel, although there will be a slowdown across the board. Whether it's noticeable will depend on the relationship between the load Enkive and MongoDB are handling and the hardware Enkive is running on. The index won't be used until it's entirely created, so those queries that would benefit from the existence of the index will run more slowly. Creating the index in the background is the generally recommended choice.
The administrator can choose to time the creation of one or more indexes with periods of lower email volume and/or less e-discovery interaction.
Using choice s the administrator can skip the given index. Choice r will cause any remaining missing indexes to be reported without the option to create. Finally choice q will simply exit the tool.