Description
The slee-data-migration tool is responsible for persisting some parts of the system configuration:
-
profile specs
-
profile table names
-
RA properties
-
log settings
-
SNMP OID and counter values.
We need to persist this configuration from the old installation in both minor and major upgrades.
In a major upgrade, the slee-data-migration tool is also used to extract this same information from the
newly installed but not yet configured uplevel system, to provide as additional information to the transformation process.
The slee-data-transformation is then passed the 2 sets of output from the slee-data-migration tool,
and it uses the profile specs and RA properties in that output to make a transformed configuration
that conforms to the schema of the new installed system.
The tool also takes a complete record of the versions of all components in the downlevel and uplevel installations, to allow the transformation stage to tailor its behaviour appropriately.
In both minor and major upgrades, the slee-data-migration tool is then called again to apply
the appropriate configuration back to the new installed system:
-
recreate the profile tables that are not in the new system but are present in the configuration data
-
apply the RA configuration
-
set the log settings back
-
ensure the same SNMP OID and counter values are retained.
SNMP OID handling
When the data-migration-tool reapplies OID values from the downlevel system to the uplevel one it
-
uses the downlevel OID value for any feature that is retained in the uplevel system
-
makes sure that any features deleted from the uplevel system do not have an OID value, and that no other feature uses that OID value
-
makes sure that features that were renamed in the upgrade retain the same OID as the previously named one did in the downlevel system
-
assigns new OID values to any added features, where the OID values follow on from the ones previously used
Similar logic applies to stats counters.
Usage options
The tool is meant to be used as part of minor and major upgrade and not as a standalone tool, nevertheless there might be cases where other tools might use it so this is how to invoke the tool. The package has a shell script that wraps the Java calls.
Option "-c (--client-dir)" is required
Usage: data-migration.sh -c CLIENT_DIR <-e FILE | -i FILE [-r]>
-c (--client-dir) CLIENT_DIR : Rhino client directory
-e (--export) FILE : Save profile tables to the given file
-h (--help) : Print usage information (default: false)
-i (--import) FILE : Load profile tables from the given file
-l (--log-file) LOG_FILE : File to log to
-r (--recreate) : Destroy and recreate profile tables when
importing (default: false)
-s (--skip-feature-scripts) : Skip deleting the feature point and feature
scripts tables (default: false)
The tool uses Rhino Management MBean interfaces to retrieve and restore the data from a running Rhino. The configuration is persisted in JSON format. The normal usage is:
retrieve existing configuration
data-migration.sh --client-dir <path to the Rhino client> --export <file to persist the configuration> --log-file <optional log file>
restore the configuration
data-migration.sh --client-dir <path to the Rhino client> --import <file to restore the configuration> --log-file <optional log file>
The --recreate and --skip-feature-scripts are set differently depending if the tool is being used during a minor upgrade or major upgrade.
For minor upgrade, orca calls the tool with -recreate. It has the effect of cleaning all existing profiles, so the configuration is exactly the same as before.
It is done this way because schema changes are not expected during a minor upgrade.
For major upgrade, orca uses --skip-feature-scripts. This way the new version of feature scripts are maintained because they are the correct ones for that version.
