cudbOperator users have no access to run this command.

• Format (1): cudbAnalyser -l | --logfile <logfile> -p | --previous-logfile <previous-logfile> [-s | --save-counter] [-q | --quiet] [-d | --debug] [-S | --send-alarm] [-w | --weight-threshold <threshold>]

• Format (2): cudbAnalyser -a | --auto-check [-s | --save-counter] [-q | --quiet] [-d | --debug] [-S | --send-alarm] [-w | --weight-threshold <threshold>]

• Format (3): cudbAnalyser -h | --help

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -l <logfile> | --logfile <logfile> : Points to the newer log file.

• -p | --previous-logfile <previous-logfile> : Points to an older logfile.

  Note:

  The timestamp of <logfile> must be newer than <previous-logfile> to receive a correct differential analysis.

• -s | --save-counter: Saves a counter under /home/cudb/monitoring/preventiveMaintenance/cudb_analyser_error_counter.log which shows the number of failing checks. This is needed for ESA integration.

• -a | --auto-check: The script checks the last two log files automatically. The use of the --logfile and --previous-logfile switches is not necessary in this case.

• -q | --quiet: Makes the error printouts less verbose.

• -d | --debug: Restricted for Ericsson personnel.

• -S | --send-alarm: Sends an alarm to ESA, based on the results.

• -w | --weight-threshold <threshold> : Prints errors if WEIGHT is greater or equal to the weight threshold (default value is 2). When performing a detailed system audit, set this value to 0 to print more errors.

cudbOperator users have no access to run this command.

cudbApplicationCounters -C | --Counter-file <counter_configuration_file> -U | --Unique <uniqueNumber> [-f | --file-config <configuration_file>] [-u | --user-facility <facility_level>] [-l | --licensing] [-D | --Debug] [-h | --help]

The following command options can be used:

• -C | --Counter-file <counter_configuration_file> : Selects the file which contains the information required for generating counters and storing them in Processing Layer Database (PLDB).

• -f | --file-config: Sets the XML file with the data of the entire CUDB system.

• -U | --Unique: Unique number greater than 0 between process instances.

• -u | --user-facility: Restricted for Ericsson personnel.

• -l | --licensing: Restricted for Ericsson personnel.

• -D | --Debug: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

The command output shows the command version and OAM library version when executed successfully:

cudbOperator users have no access to run this command.

cudbApplyConfig [-s|--scope <scope>] [-v|--verbose] [-h|--help]

The following command options can be used:

• -s | --scope <scope> : Defines the scope of applying configuration changes. The available values of <scope> are as follows:

  • all: Requests configuration change application to all concerned entities. It is the default value.

    Attention!

    This command option is deprecated. To make configuration model changes persistent, use the administrative operation applyConfig. Refer to CUDB Node Configuration Data Model Description for more information on applyConfig.

  • init_c2l: Restricted for Ericsson personnel.

• -v | --verbose: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

The command output is a log of the performed changes. The command result is provided at the end of the log.

cudbOperator users have no access to run this command.

• Format (1): cudbCheckConsistency [-l | --locked] [-a | --alarms] [-m | --maxdiff-limit <LIMIT>] [-c | --check-limit <LIMIT>] [-v | --verbose <LEVEL>]

• Format (2): cudbCheckConsistency -h | --help

• Format (3): cudbCheckConsistency -o | --object-tables

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -l | --locked: Refuses to run if started anywhere else than on the PLDB master CUDB node, on the HA active SC. This option is useful and mandatory for running the program as a cron job.

• -a | --alarms: Allows to raise alarms if the test fails. This option is useful and mandatory when the program runs as a cron job. When started interactively, there is no need to raise alarms.

• -v | --verbose <LEVEL> : Sets the verbosity level to the defined <LEVEL> . Accepted values: '1' or '2'. A value of '1' means that detailed information about the progress of the program is printed to the console, but these extra details do not go into the system log. Level '2' means that extra details are written both to the console and to the system log.

• -m | --maxdiff-limit <LIMIT> : Uses the defined value of <LIMIT> as the maximal tolerable difference in percentage (MAXDIFF_LIMIT configuration value). <LIMIT> must be a non-negative floating point value rounded to two decimal digits in the [ 0.00 ; 100.00 ] closed interval. For example, "0.58" means 0.58% difference is allowed. The test fails if the difference is greater than the value defined for <LIMIT> .

• -c | --check-limit <LIMIT> : Does not check tables that have fewer rows than the value defined for <LIMIT> in the master DS Unit (CHECK_LIMIT configuration value). <LIMIT> must be a non-negative integer.

• -o | --object-tables: Checks for any possible differences in the OBJECT_CLASSES and the MULTI_VALUE_OBJECTS tables. Tables located on slave PLDB units will be checked against the tables located on master PLDB replica. Tables located on slave DS units will be checked both against the tables located on the corresponding master DS replica and the tables located on master PLDB replica.

  Note:

  This option must not be run as a Cron job, but only from the command line.

   [info] cudbCheckConsistency is running with options: '', MAXDIFF_LIMIT: 1.00%, CHECK_LIMIT: 100
   [info] Acquiring mastership information.
   [info] Checking consistency in slave DS units.
   [info]   Node42-DSG0 consistency: OK - row count difference 0.00%
   [info]   Node42-DSG1 consistency: OK - row count difference 0.00%
   [info]   Node42-DSG2 consistency: OK - row count difference 0.00%
   [info] Summary: slaves checked: 3 -> PASSED: 3, FAILED: 0, UNKNOWN: 0.

In this output, Node42-DSG0 refers to the PLDB.

The configuration file of the command is located in the following directory:

/home/cudb/monitoring/replicaConsistency/config/cudbCheckConsistency.conf

This file is directly included by a Bash shell script with the following prerequisites:

• Comment lines must start with a # character.

• Settings must follow the VARIABLE=VALUE pattern without white spaces around the = operator.

Maximum tolerable row count difference in PERCENTS between tables in the master DS Unit and the slave DS Unit. The difference is counted table-by-table, and if the difference is greater than the configured tolerance limit in any of the tables, the verdict is FAILED.

The value must be a floating point number with exactly two decimal digits, in the [ 0.00 ; 100.00 ] closed interval.

Default value: 1.00

Command line option: -m | --maxdiff-limit <LIMIT>

If a table in the master DS Unit has fewer rows than this check limit, then the table is skipped.

The value must be an integer number in the [ 0 ; INT_MAX ) left-closed right-open interval, where INT_MAX is the constant defined in POSIX.1-2008 Base Specifications, Issue 7.

Default value: 100

Command line option: -c | --check-limit <LIMIT>

Cron job time specification. If this value is changed, then the value must also be changed on every other CUDB node of the CUDB system, and the new value must be installed to cron on both SCs of every CUDB node. On a specific CUDB node, after saving the new value, the new settings can be installed to cron by issuing the following command on an SC:

ssh OAM1 '/etc/init.d/cudbCheckConsistencySrv restart'

ssh OAM2 '/etc/init.d/cudbCheckConsistencySrv restart'

The value must be either "disabled" or a valid cron job time specification.

Default value: '37 0 * * *'

Command line option: -

cudbOperator users have no access to run this command.

• Format (1): cudbCheckReplication [-l | --locked] [-a | --alarms] [-b | --behind-limit <LIMIT>] [-v | --verbose <LEVEL>]

• Format (2): cudbCheckReplication -h | --help

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -l | --locked: Refuses to run if started anywhere else than on the PLDB master CUDB node, on the HA active SC. This option is useful and mandatory for running the program as a cron job.

• -a | --alarms: Allows to raise alarms if an open replication channel does not work. This option is useful and mandatory for running the program as a cron job. When started interactively, there is no need to raise alarms.

• -b | --behind-limit <LIMIT> : After injecting test data into the master DS Unit of a DSG, the command waits for the specified amount of seconds (defined with <LIMIT> ) before starting to check if the data showed up in the slave DS Units. The value of <LIMIT> must be a positive integer, and its configuration variable is BEHIND_LIMIT.

• -v | --verbose <LEVEL> : Sets the verbosity level to the defined <LEVEL> . Accepted values are '1' or '2'. A value of '1' means that detailed information about the execution progress is printed to the console, but these extra details are not included in the system log. Level '2' means that the extra details are written both to the console and to the system log.

The command can display the following example output:

   [info] cudbCheckReplication is running with options: '', BEHIND_LIMIT: 10
   [info] Acquiring mastership information.
   [info] Acquiring DSG status information.
   [info] Injecting verification data to master DS units.
   [info] Sleeping 10 seconds to wait for replication.
   [info] Checking replication in slave DS units.
   [info]   Node42-DSG0 replication: OK
   [info]   Node42-DSG1 replication: OK
   [info]   Node42-DSG2 replication: OK
   [info] Summary: channels checked: 3 -> PASSED: 3, FAILED: 0, UNKNOWN: 0.

The configuration file of the command is located in the following directory:

/home/cudb/monitoring/replicaConsistency/config/cudbCheckReplication.conf

This file is directly included by a Bash shell script with the following prerequisites:

• Comment lines must start with a # character.

• Settings must follow the VARIABLE=VALUE pattern without white spaces around the = operator.

This setting assumes that any data injected to a master DS Unit are replicated within the defined amount of seconds to the slave DS Units. If the verification data does not arrive after the amount of seconds defined with BEHIND_LIMIT, the test verdict is FAILED. The value must be an integer number in the [ 1 ; INT_MAX ) left-closed right-open interval, where INT_MAX is the constant defined in POSIX.1-2008 Base Specifications, Issue 7.

Default value: 10

Command line option: -b | --behind-limit <LIMIT>

This setting is the cron job time specification. If this value is changed, then the value must also be changed in every other CUDB node of the CUDB system, and the new value must be installed to cron on both SCs of every CUDB node. On a specific CUDB node, after saving the new value, you can install the new settings to cron by issuing the following command on the SCs:

ssh OAM1 '/etc/init.d/cudbCheckReplicationSrv restart'

ssh OAM2 '/etc/init.d/cudbCheckReplicationSrv restart'

The value must be either "disabled" or a valid cron job time specification.

Default value: '7 0 * * *'

Command line option : -

cudbOperator users have no access to run this command.

Restrictions of cudbCollectInfo command:

• Only one instance of cudbCollectInfo command can be executed in one CUDB node

• Only one instance of cudbCollectInfo command at a time can collect logs from a target CUDB node

• Only one system-wide cudbCollectInfo command at a time can be executed in the CUDB system

• A system-wide cudbCollectInfo command precludes any other cudbCollectInfo command from running anywhere in the system

cudbCollectInfo [-n | --node <node id>] [-d | --ds <dsg id>] [-a | --action <action name>] [-c | --no-compress] [-e | --no-encrypt] [-h | --help] [-x | --exit-on-error]

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -n | --node <node id> : Defines the node where logs must be collected. Use the ID of a CUDB node to define a specific node, or "all" to collect logs for all nodes. If the -n option is not used, the logs will be automatically collected from all the nodes in the system.

• -d | --ds <dsg id> : Defines the DSGs where the logs must be collected. Use the ID of the DSG to define a specific DSG, or "all" to collect logs for all DSGs. This option only applies to ndb_error_reporter logs, which are retrieved from local DS Units belonging to the specified DSGs. If the -d option is not used, the logs will be automatically collected from all the DSGs.

• -c | --no-compress: Disables the compression of the collected logs to an archive.

• -e | --no-encrypt: Disables the GPG encryption of the tgz archive.

• -x | --exit-on-error: Exits the command when an error is found during collection. Default behavior is not to exit.

• -a | --action <action name> : <action name> is the name of the log collecting action to execute. If the -a option is not used, all collecting actions will be performed as if the -n all option is used.

  The available actions are as follows:

  • ndb_error_reporter

  • collect_info

  • sm

  • esa

  • cluster_config

  • measurement

  • ldapfe

  • system_status

  • bc_server

  • evip

  • ddci

  • bc_client

  • upgrade

  • all: This action is equivalent to specifying all other actions together.

The following list contains some example output messages:

• cudbCollectInfo -n 1

Creating dir for node 1 (/local/tmp/cudb_collect_info_20120412-104337/1) ... OK 

 Waiting 1 to finish ... OK 


 CREATING ARCHIVE ... OK 
 Encrypting archive ... OK 
 Removing unencrypted archive ... OK 


 REMOVING RAW DATA ... OK 


 Fetch the file: /local/tmp/cudb_collect_info_20120412-104337.c

In case cudbCollectInfo is already running on a local node or on a remote node (from another terminal or from another node in the system), the following output messages are printed to the console:

• cudbCollectInfo -n <local node-id>

cudbCollectInfo is already running on this node. 

• cudbCollectInfo -n <remote node-id>

cudbCollectInfo is already running on node <Node ID where the command is executing>.

• cudbCollectInfo -n <remote node-id>

cudbCollectInfo is already running for node <target node ID> on node 
<Node ID where the command is executing>.

The user permissions of executing cudbConsistencyMgr are as follows:

• Root permission is required to run the command.

• cudbadmin can run this command through sudo without password.

• cudbOperator users have no access to run this command without password.

• Format (1): cudbConsistencyMgr -h | --help

• Format (2): cudbConsistencyMgr -v | --version

• Format (3): cudbConsistencyMgr -l | --list

• Format (4): cudbConsistencyMgr -t | --taskhistory

• Format (5): cudbConsistencyMgr -r | --remove <taskId> [-f | --force]

• Format (6): cudbConsistencyMgr -o | --order ms -n | --node <nodeid> -p | --pl [--max-replica-lag <milliseconds>] [--alarm-severity-limit <threshold>] [-D | --debug] [--debugStderr] [--task-debug] [--task-verbose]

• Format (7): cudbConsistencyMgr -o | --order ms -n | --node <nodeid> -d | --dsg <dsgid> [--max-replica-lag <milliseconds>] [--alarm-severity-limit <threshold>] [-D | --debug] [--debugStderr] [--task-debug] [--task-verbose]

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -v | --version: Prints version information and exits.

• -l | --list: Lists elements of the Pending Task List (PTL) and the Running Task List (RTL), then exits.

• -t | --taskhistory: Prints the contents of the local task history log on the screen, then exits.

• -r | --remove <taskID> : Removes the task specified by <taskID> from the PTL.

• -f | --force: Forces the removal of the task by trying to follow the task even in the RTL.

• -o | --order ms: Orders master-slave consistency check between the master and slave replicas selected by the -d | --dsg, -p | --pl and -n | --node command options.

• -n | --node <nodeid> : Defines the node ID of the slave replica which is subject to the consistency check.

• -p | --pl: Selects the PLDB for consistency check.

• -d | --dsg<dsgid> : Selects the DSG with the specified <dsgid> for consistency check.

• [--max-replica-lag <milliseconds>] (default value: 10000): This parameter sets the maximum tolerable replication distance between the master and the slave. The value is provided in milliseconds, and it defines the execution conditions for the check task. The value of 10000 means that the check task is not started, and respectively a running task is stopped, if the replication lag reaches or exceeds 10000 ms.

• [--alarm-severity-limit <threshold>] (default: 500): This parameter is used to control the severity of the alarm that is raised when inconsistency is found. If the number of inconsistent rows is higher than the <threshold> value, then a major severity alarm is raised instead of the default severity.

• [--task-verbose]: Restricted for Ericsson personnel.

• [--task-debug]: Restricted for Ericsson personnel.

• -D | --debug: Restricted for Ericsson personnel.

• --debugStderr: Restricted for Ericsson personnel.

The output of the cudbConsistencyMgr command depends on the specified command options. Some examples are provided below.

Scheduling-Related Output

Task UTC_2014-09-23-17-05-42_N242_U0000001955 is put into the pending task list and will be executed on node 242.

Task Listing-Related Output

[Site 1]

        RTL:
                UTC_2014-09-09-11-00-10_N121_U0000000849
                        checkType=ms,source=S1-N121-D1,check=S2-N122-D1,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
        PTL:

[Site 2]

        RTL:
                UTC_2014-09-09-11-00-16_N122_U0000000793
                        checkType=ms,source=S2-N122-D2,check=S1-N121-D2,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
        PTL:
                UTC_2014-09-09-11-00-17_N122_U0000000794
                        checkType=ms,source=S2-N122-D2,check=S1-N121-D2,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
                UTC_2014-09-09-11-00-21_N122_U0000000795
                        checkType=ms,source=S2-N122-D3,check=S1-N121-D3,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
                UTC_2014-09-09-11-00-22_N122_U0000000796
                        checkType=ms,source=S2-N122-D3,check=S1-N121-D3,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
                UTC_2014-09-09-11-00-23_N122_U0000000797
                        checkType=ms,source=S2-N122-D3,check=S1-N121-D3,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
                UTC_2014-09-09-11-00-23_N122_U0000000798
                        checkType=ms,source=S2-N122-D3,check=S1-N121-D3,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off
                UTC_2014-09-09-11-00-23_N122_U0000000799
                        checkType=ms,source=S2-N122-D3,check=S1-N121-D3,maxReplicaLag=2000,alarmSeverityLimit=500,\
                        verboseMode=off,debugMode=off

Task History-Related Output

The output in this case consists of log lines describing the following information:

• The time when each task was added to the PTL.

• The time when each task was started and finished.

• The result of the task executions.

The results are ordered by time, and are listed from the oldest to the newest, as shown below:

2014-09-23 15:53:49+02:00 SC_2_1 UTC_2014-09-23-13-53-48_N243_U0000000586: task found in PTL
checkType=ms,source=S2-N243-D1,check=S1-N242-D1,maxReplicaLag=2000,alarmSeverityLimit=500,verboseMode=off,debugMode=off

2014-09-23 15:53:49+02:00 SC_2_1 UTC_2014-09-23-13-53-48_N243_U0000000586: task execution started

2014-09-23 15:54:00+02:00 SC_2_1 UTC_2014-09-23-13-53-48_N243_U0000000586: task execution finished with result:
Successful completion, no difference found. Exit code: 0.

cudbOperator users have no access to run this command.

• Format (1): cudbDataBackup [-T | --Timeout <seconds>] [-R | --Retries-number <number_of_retries>] [-t | --time <seconds>] [-S | --Slack-backup <minutes>] [-F | --Force] [-q | --DisablePG] [-L | --Parallel-mode] [-u | --user-facility <facility>] [-p | --print] [-D | --Debug]

• Format (2): cudbDataBackup -s | --schedule <cron_expression> [-T | --Timeout <seconds>] [-R | --Retries-number <number_of_retries>] [-t | --time <seconds>] [-S | --Slack-backup <minutes>] [-F | --Force] [-q | --DisablePG] [-L | --Parallel-mode] [-u | --user-facility <facility>] [-p | --print] [-D | --Debug]

• Format (3): cudbDataBackup -U | --Unschedule <cron_expression> [-T | --Timeout <seconds>] [-R | --Retries-number <number_of_retries>] [-t | --time <seconds>] [-S | --Slack-backup <minutes>] [-F | --Force] [-q | --DisablePG] [-L | --Parallel-mode] [-u | --user-facility <facility>] [-p | --print] [-D | --Debug]

• Format (4): cudbDataBackup -h | --help

The following command options can be used:

• -T | --Timeout <seconds> : Restricted for Ericsson personnel.

• -R | --Retries-number <number_of_retries> : Defines the number of retry attempts to establish the connection to the CUDB node where a specific piece of the data backup program is taken, if it fails the first time. The default value is 2.

• -t | --time <seconds> : Defines the time (in seconds) between retries. The default value is 5 seconds.

• -S | --Slack-backup <minutes> : Defines the time (in minutes) available to finish the provisioning operations before starting the backup. The default value is 2 minutes.

• -F | --Force: Forces the backup, even if the notification to the Provisioning Gateway (PG) fails.

• -q | --DisablePG: Disables PG notification.

• -L | --Parallel-mode: Orders a backup for each CUDB node element (that is for the PLDB and all DS Units like DS1, DS2, and so on) at the same time instead of one after another (that is, not when the previous one is finished).

• -u | --user-facility <facility> : Restricted for Ericsson personnel.

• -s | --schedule: Creates a periodic system data backup according to the defined <cron_expression> . The cron expression follows the below UNIX format:

  <minute> <hour> <day_of_month> <month_of_year> <day_of_week>

  The accepted values and value ranges are as follows:

  • <minute>: <0 - 59>

  • <hour>: <0 - 23>

  • <day_of_month>: <1 - 31>

  • <month_of_year>: <1 - 12>

  • <day_of_week>: <0 - 7>

    Note:

    Values 0 and 7 for <day_of_week> both mean the same day, Sunday.

  Every value can be replaced with an asterisk ("*"), meaning all possible values for the field. See the below execution for an example:

  cudbDataBackup -s "5 0 * * *"

  Note:

  In case the -s | --schedule option is used, then any additional cudbDataBackup options listed in this section must be stated after this option.

• -U | --Unschedule: Removes a periodic system data backup according to the defined <cron_expression> . The cron expression follows the same format as described for the -s | --schedule command option. This command option must be executed with the same optional arguments that were used to set the schedule.

• -p | --print: Prints the information of the scheduled periodic system data backup.

• -D | --Debug: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

The command output is a log of the performed changes. The command result is provided at the end of the log.

cudbOperator users have no access to run this command.

• Format (1): cudbDbDiskManage -a | --allocate <objectClass> <size>

• Format (2): cudbDbDiskManage -l | --list <objectClass>

• Format (3): cudbDbDiskManage -h | --help

The following command options can be used:

• -a | --allocate <objectClass> <size> : Allocates extra space for the BLOB attributes stored on the disk storage system belonging to the object class defined with <objectClass> . The <size> is in megabytes and is rounded up to the following multiple of 128 as long as the provided value is greater than 128; otherwise, the exact size is added.

• -l | --list <objectClass> : Lists the occupied and free space for storing attribute values on the disk storage system for the object class defined with <objectClass> . Refer to CUDB Application Schema Update for more information on the available object classes.

• -h | --help: Displays command help message and exits.

The command reports OK in case of success, and error in case of failure.

cudbOperator users have no access to run this command.

• Format (1): cudbDsgMastershipChange -d | --dsg <dsgId> [-t | --time <seconds>] [-D | --Debug] [--force [--no-prompt]]

• Format (2): cudbDsgMastershipChange -p | --pl [-t | --time <seconds>] [-D | --Debug] [--force [--no-prompt]]

• Format (3): cudbDsgMastershipChange -h | --help

The following command options can be used:

• -d | --dsg <dsgId> : Identifies the DSG where the master change is executed. The value of <dsgId> must be between 1 and 255.

• -p | --pl: Refers to the local PLDB cluster.

• -t | --time <seconds> : Defines the time (in seconds) of the allowed synchronization delay between the current master replica and the future master replica to perform the mastership change. In case the current master replica is not close enough, the command exits and does not perform the mastership change. The default value is 3 seconds.

• -D | --Debug: Restricted for Ericsson personnel.

• --force: Forces to complete the mastership change, even in the following cases:

  • The PLDB is unable to synchronize on the node where the command is invoked.

  • The PLDB replication status information is unavailable on the node where the command is invoked.

  • Replication channels are unavailable.

  • The replication in the new target master does not align with the current master.

  This option is not exclusive with --time. To force a mastership change with great distance between the new master and the current master, use a great value for the --time parameter.

• -h | --help: Displays command help message and exits.

• --no-prompt: Restricted for Ericsson personnel only.

The possible outputs for the command are as follows:

• In case of successful mastership change:

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Success. 
    DSG 2 master replica moved from node N2 to N3 successfully.

  • Processing PL mastership change... 
    cudbDsgMastershipChange: Success. 
    PL master replica moved from node N2 to N3 successfully.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Success. 
    The node already has the master replica of the specified DSG.

• In case of failed mastership change:

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    DSG 2 master replica can not be moved to node N3 because replication with node N2 is not aligned.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    Replication channel is not up. 

    Note:

    In the two cases above, an error message is also provided describing the situation. In these cases, the --force option can be used to proceed with the mastership change. However, consider that in this case, the mastership change most probably results in data loss because the candidate master cannot be synchronized with the current master. In case of data loss, replication fails, and the Storage Engine, Unable to Synchronize Cluster in DS, Major or Storage Engine, Unable to Synchronize Cluster in PLDB, Major alarms are raised. Refer to the appropriate alarm OPI for more information on how to clear the alarm.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    Replication is delayed more than 3 secs.

    Note:

    In the latter example, the --time option can be used to increase the allowed synchronization time delay between replicas. If the mastership still cannot be changed because the candidate master cannot align with the current master, the --force option can be used in addition to the --time option to force the change.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    DSG 2 master replica can not be moved. Check site SM leader logs.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    The DSG specified is masterless.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    The DS hosting the specified DSG in the node where the command is invoked is disabled.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    The node hosting the specified DSG has PL down or no SM available.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    The specified DSG is not alive.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    There is no replica distance info in BC cluster. 

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    The PLDB is unable to synchronize on the node where the command is invoked.

  • Processing DSG mastership change... 
    cudbDsgMastershipChange: Failed. 
    Replication status info for PLDB on the node where the command is invoked is not available.

• When attempting to move the DSG master to a degraded replica, the following warning message is shown:

  Processing DSG mastership change...
  WARNING: The master will be moved to a degraded replica.
  cudbDsgMastershipChange: Success.
  DSG 1 master replica moved from node N1 to N2 successfully.

cudbOperator users have no access to run this command.

• Format (1): cudbDsgProvisioningManage -e | --enable <DSGId> [-D | --Debug]

• Format (2): cudbDsgProvisioningManage -d | --disable <DSGId> [-D | --Debug]

• Format (3): cudbDsgProvisioningManage -s | --status <DSGId> [-D | --Debug]

• Format (4): cudbDsgProvisioningManage -h | --help

The following command options can be used:

• -e | --enable <DSGId> : Enables provisioning in the specified DSG. <DSGId> must be a valid DSG identifier present in the system.

• -d | --disable <DSGId> : Disables provisioning in the specified DSG. <DSGId> must be a valid DSG identifier present in the system.

• -s | --status <DSGId> : Shows the provisioning status of the specified DSG. <DSGId> must be a valid DSG identifier present in the system. The possible return values are enable or disable for provisioning.

• -D | --Debug: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

An example output of the command is shown below:

cudbDsgProvisioningManage: Failed. 
Invalid syntax

cudbDsgProvisioningManage: Failed. 
Unrecognized command line argument or arguments

cudbDsgProvisioningManage: Failed. 
DSG %d is not valid

cudbDsgProvisioningManage: Failed.
Unexpected error.

cudbDsgProvisioningManage: Success. 
DSG %d is already enabled.

cudbDsgProvisioningManage: Success. 
DSG %d is already disabled.

cudbDsgProvisioningManage: Success. 
DSG %d is enabled for provisioning.

cudbDsgProvisioningManage: Success. 
DSG %d is disabled for provisioning

cudbOperator users have no access to run this command.

cudbGetLogs [-d | --debug] [-b | --bash-debug] [-c | --consistency-threshold <threshold>] [-f | --force-c-check] [-h | --help]

The following command options can be used:

• -d | --debug: Restricted for Ericsson personnel.

• -b | --bash-debug: Restricted for Ericsson personnel.

• -c | --consistency-threshold <threshold> : Sets the lightweight consistency check error threshold (the default value is 500).

• -f | --force-c-check: Forces the lightweight consistency check to run.

• -h | --help: Displays command help message and exits.

An example output for the command is provided below:

Starting /opt/ericsson/cudb/OAM/bin/cudbGetLogs ... 
Grepping logs and creating /home/cudb/monitoring/preventiveMaintenance/CUDB_107_201201241136.log ... 
The log file is saved as : /home/cudb/monitoring/preventiveMaintenance/CUDB_107_201201241136.log

cudbOperator users have no access to run this command.

cudbHaState

Not applicable.

The output shows the LDE and AMF cluster state, the CoreMW, COM state and the SI and SU states. The output must be similar to the below example:

LOTC cluster uptime:
 --------------------
Sat Apr 20 18:33:30 2013
 LOTC cluster state:
 -------------------
 Node safNode=SC_2_1 joined cluster | Sat Apr 20 18:33:40 2013
 Node safNode=SC_2_2 joined cluster | Sat Apr 20 18:33:30 2013
 Node safNode=PL_2_3 joined cluster | Sat Apr 20 18:35:39 2013
 Node safNode=PL_2_4 joined cluster | Sat Apr 20 18:35:43 2013
 Node safNode=PL_2_5 joined cluster | Sat Apr 20 18:35:43 2013
 Node safNode=PL_2_6 joined cluster | Sat Apr 20 18:35:43 2013
 Node safNode=PL_2_7 joined cluster | Sat Apr 20 18:35:48 2013
 Node safNode=PL_2_8 joined cluster | Sat Apr 20 18:35:48 2013
 Node safNode=PL_2_9 joined cluster | Sat Apr 20 18:35:53 2013
 Node safNode=PL_2_10 joined cluster | Sat Apr 20 18:35:48 2013
 AMF cluster state:
 ------------------
 saAmfNodeAdminState."safAmfNode=SC-1,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=SC-1,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=SC-2,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=SC-2,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-3,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-3,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-4,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-4,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-5,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-5,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-6,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-6,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-7,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-7,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-8,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-8,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-9,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-9,safAmfCluster=myAmfCluster": Enabled
 saAmfNodeAdminState."safAmfNode=PL-10,safAmfCluster=myAmfCluster": Unlocked
 saAmfNodeOperState."safAmfNode=PL-10,safAmfCluster=myAmfCluster": Enabled
 CoreMW HA state:
 ----------------
 CoreMW is assigned as ACTIVE in controller SC-2
 CoreMW is assigned as STANDBY in controller SC-1
 COM state:
 ----------
 COM is assigned as ACTIVE in controller SC-2
 COM is assigned as STANDBY in controller SC-1
 SI HA state:
 ------------
 saAmfSISUHAState."safSu=SC-2,safSg=2N,safApp=ERIC-CUDB_CUDBOI"."safSi=2N-1": active(1)
 saAmfSISUHAState."safSu=SC-1,safSg=2N,safApp=ERIC-CUDB_KPICENTRAL"."safSi=2N-1": active(1)
 saAmfSISUHAState."safSu=SC-2,safSg=DS1_2N,safApp=ERIC-CUDB_CS"."safSi=DS1_2N-1": active(1)
 saAmfSISUHAState."safSu=SC-2,safSg=DS2_2N,safApp=ERIC-CUDB_CS"."safSi=DS2_2N-1": active(1)
 saAmfSISUHAState."safSu=SC-2,safSg=PLDB_2N,safApp=ERIC-CUDB_CS"."safSi=PLDB_2N-1": active(1)
 saAmfSISUHAState."safSu=SC-2,safSg=2N,safApp=ERIC-CUDB_LDAPFE_MONITOR"."safSi=2N-1": active(1)
 saAmfSISUHAState."safSu=SC-1,safSg=2N,safApp=ERIC-CUDB_CUDBOI"."safSi=2N-1": standby(2)
 saAmfSISUHAState."safSu=SC-1,safSg=2N,safApp=ERIC-CUDB_LDAPFE_MONITOR"."safSi=2N-1": standby(2)
 saAmfSISUHAState."safSu=SC-1,safSg=2N,safApp=ERIC-CUDB_MSGSRV_MONITOR"."safSi=2N-1": active(1)
 saAmfSISUHAState."safSu=SC-1,safSg=DS2_2N,safApp=ERIC-CUDB_CS"."safSi=DS2_2N-1": standby(2)
 saAmfSISUHAState."safSu=SC-1,safSg=DS1_2N,safApp=ERIC-CUDB_CS"."safSi=DS1_2N-1": standby(2)
 saAmfSISUHAState."safSu=SC-1,safSg=PLDB_2N,safApp=ERIC-CUDB_CS"."safSi=PLDB_2N-1": standby(2)
 saAmfSISUHAState."safSu=PL-3,safSg=2N,safApp=ERIC-CUDB_SOAP_NOTIFIER"."safSi=2N-1": active(1)
 saAmfSISUHAState."safSu=PL-4,safSg=2N,safApp=ERIC-CUDB_SOAP_NOTIFIER"."safSi=2N-1": standby(2)
 SU States:
 ----------
 Status OK

cudbOperator users have no access to run this command.

cudbLdapFeRestart [-f | --force] [-p | --parallel [--no-prompt]] [-h | --help]

The following command options can be used:

• -p | --parallel: Restricted for Ericsson personnel.

  Caution!

  Never use the command option above in a live system. Use it only during node installation, otherwise traffic loss and degradation can occur.

• --no-prompt: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

• -f | --force: Continue with the restart, even if any slapd process fail to start.

The command output is a log of the command progress. The result of the command is provided at the end of the log.

This command acts on the BC server running on the blade or Virtual Machine (VM) where it is executed.

• Format (1): cudbManageBCServer -check

• Format (2): cudbManageBCServer -check4

• Format (3): cudbManageBCServer -checkMode

• Format (4): cudbManageBCServer -start

• Format (5): cudbManageBCServer -stop

• Format (6): cudbManageBCServer -restart

• Format (7): cudbManageBCServer -restart -no_check

• Format (8): cudbManageBCServer -h | --help

The following command options can be used:

• -check: Checks if a BC server is running on the blade or VM.

• -check4: By using a four-letter command, this option checks if the process is running and if it is connected to a BC cluster with the majority of BC servers.

• -checkMode: Checks if the specific BC server is the leader of the cluster, or just a follower.

• -start: Starts a BC Server in the blade or VM.

• -stop: Stops a BC Server in the blade or VM.

• -restart: Restarts a BC Server in the blade or VM.

• -restart -no_check: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

cudbOperator users have no access to run this command.

cudbManageLibDataDist [-l | --load] [-0 | --unload] [-s | --status] [-h | --help]

The following command options can be used:

• -1 | --load: Loads a new library stored in the following temporary folder: /home/cudb/oam/configMgmt/commands/tmp.

• -0 | --unload: Unloads the library stored in /usr/lib/.

• -s | --status: Checks the status of the distribution policy.

• -h | --help: Displays command help message and exits.

The command must return an output similar to the below example:

Customer distribution policy active

This command acts on the MsgSrv server running on the blade or VM where it is executed.

• Format (1): cudbManageMsgSrvServer status

• Format (2): cudbManageMsgSrvServer start

• Format (3): cudbManageMsgSrvServer stop

• Format (4): cudbManageMsgSrvServer restart

The following command options can be used:

• status: Checks if a MsgSrv server is running on the blade or VM.

• start: Starts a MsgSrv server in the blade or VM.

• stop: Stops a MsgSrv server in the blade or VM.

• restart: Restarts a MsgSrv server in the blade or VM.

The result the command depends on the option used. For example:

• status:

  Status of Messaging Service server: <UP|DOWN>, pid:<PID>

• start:

  Starting Messaging Service server OK or Messaging Service server 
  already running, pid: <PID>

• stop:

  Stopping Messaging Service server OK

The requisites of executing this command are as follows:

• cudbOperator users have no access to run this command.

• The command requires execution confirmation for some options.

• Format (1A): cudbManageStore -p | --pl -o | --order <orderName> [--no-prompt] [-l | --location <backupPath>] [--Script-path | -S <sqlPath>] [--no-start-replication | -n] [ --no-ldapfe-restart | -x ] [--restore-stored-procedures | -s] [--fresh-backup | -f]

• Format (1B): cudbManageStore -p | --pl -o | --order <initndb> -i | --ndbid <ndbid>

• Format (2A): cudbManageStore -d | --ds {<dsId>,<dsId>,...} -o | --order} <orderName> [-l | --location <backupPath>] [--Script-path | -S <sqlPath>] [--no-start-replication | -n][ --no-ldapfe-restart | -x ] [--restore-stored-procedures | -s] [ --fresh-backup | -f ]

• Format (2B): cudbManageStore -d | --ds <dsId> -o | --order <initndb> -i | --ndbid <ndbid>

• Format (3): cudbManageStore -a | --all -o | --order <orderName> [--no-prompt] [-l | --location <backupPath> [--Script-path | -S <sqlPath>] [--no-start-replication | -n] [--restore-stored-procedures | -s] [ --fresh-backup | -f ]

• Format (4): cudbManageStore -h | --help

The following command options can be used:

• -p | --pl: Specifies the local PLDB cluster.

• -d | --ds <dsId> : Specifies the local DS clusters. <dsId> can take the following values:

  • 1 to 17: The dsId corresponding to each DSG cluster configured in the CUDB node. Applies to the specified DSG storage clusters.

  • all: Applies to all DSG clusters configured in the CUDB node.

• -a | --all: Refers to all the local clusters (both PLDB and DSG).

• -o | --order <ordername> : Executes the specified administrative order. The allowed orders in a CUDB storage engine are as follows:

  • backup: Performs a cluster data backup.

  • initialize: Starts the cluster from scratch and rules out all its previous data.

  • maintenance: Takes the cluster out of service. Not involved in master movement decisions.

  • initndb: Restricted for Ericsson personnel.

  • kickstart: This order starts replication in the cluster. The order can be used only when a CUDB node is initially installed, when a system data restore or a group data restore is executed, or when a new DSG or PLDB replica is added into the CUDB system.

  • mysqldslvrestart: Restricted for Ericsson personnel.

  • mysqldch1mstrestart: Restricted for Ericsson personnel.

  • mysqldch2mstrestart: Restricted for Ericsson personnel.

  • mysqldacsrestart: Restricted for Ericsson personnel.

  • ndbrestart: Performs a rolling restart on the database nodes in the cluster.

  • masterreplicationrestart: Restarts master processes for a specific storage or DSG

  • ready: Joins back the cluster to the CUDB system from maintenance mode.

  • refresh: Forces the cluster to read configuration.

  • restart: Restarts the cluster taking into account its previous data.

  • restore: Loads a previous data backup in the cluster.

  • start: Starts the cluster, taking into account its previous data when it was stopped.

  • status: Shows the cluster status. The possible return values are as follows:

    • is being initialized

    • is being restored

    • is being performing a backup

    • is being stopped

    • is Stopped

    • is Maintenance Mode

    • is being (re)Started

    • is being refreshed

    • executing kickstart order

    • is in ready mode

  • stop: Stops all processes belonging to the cluster.

  • toggledebug: Toggles debug log for the Cluster Supervisor (CS) processes.

  • mgmnoderestart: Forces to restart the NDB mgm in the node.

  • restorestoredprocedures: Restores stored procedures for application counters.

• --no-prompt: Restricted for Ericsson personnel.

• -l | --location <backupPath> : Specifies the backup path from which backup files can be obtained from each NDB node belonging to the involved database cluster. If this path is not provided when the restore order is requested, then the default path of the cluster (specified with the BackupDataDir entry of the config.ini file in the [ndbd default] section) is applied.

• -S | --Script-path: Specifies a SQL script to be run after the restore process is successfully finished. If <sqlPath> is not provided, the default script applies. This option is used only to restore the process over a data partition belonging to the PLDB.

• -i | --ndbid: Restricted for Ericsson personnel.

• -n | --no-start-replication: Used to disable automatic replication start after a successful restore operation. Use this option only after a Group Data Restore. Refer to CUDB Backup and Restore Procedures for further information.

• -x | --no-ldapfe-restart: Used to disable reestablishing connections to the LDAP FE.

• -f | --fresh-backup: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

• -s | --restore-stored-procedures: Stored procedures of application counters are also restored after a successful restore order.

An example of command output is shown below:

cudbManageStore stores to process: pl. 
Store pl is in ready mode. 
cudbManageStore command successful.

The requisites of using the command are as follows:

• This command is executed in all CUDB nodes to ensure that the same PM configuration is used in the whole CUDB system.

• cudbOperator users have no access to run this command.

cudbPmJobReload [-t | --time <timeout>] [-D | --Debug] [-u | --user-facility <facility_level>] [-h | --help]

The following command options can be used:

• -t | --time-out <timeout> : Sets the timeout, in seconds, to try the operations. The default value is 10 seconds.

• -D | --Debug: Restricted for Ericsson personnel.

• -u | --user-facility <facility-level> : Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

When executed, the command must return an output similar to the below example:

Stopping PmAgent in node 10.22.27.10 ... OK 
Waiting for ESA PmAgent to go off line. 
ESA PmAgent has been successfully stopped. 
Starting PmAgent in node 10.22.27.10 ... OK

cudbOperator users have no access to run this command.

• Format 1 : cudbPrepareStore -p | --pl [ -s | --scope <scopeValue>]

• Format 2: cudbPrepareStore -d | --ds <dsId> [ -s | --scope <scopeValue>]

• Format 3: cudbPrepareStore -a | --all [ -s | --scope <scopeValue>]

The following command options can be used:

• -p | --pl: Runs the command for the local PLDB cluster.

• -d | --ds <dsId> : Runs the command for the local DS cluster defined with <dsId> . The value of <dsId> is the ID of the specific DS Unit, indicated either with an integer between 1-17 (for example, 1 stands for DS1, while 17 means DS17), or with "all" if the command must be executed for all local DS Units.

• -a | --all: Runs the command for all local clusters (both PLDB and DSG) configured in the specific CUDB node.

• -s | --scope <scopeValue> : Optional command option defining the scope of the command. The value of <scopeValue> can be either appsrv (referring to application scope) or all (referring to all scope).

  Note:

  If --scope <scopeValue> is not used, the command is executed with the --scope all setting by default.

An example output of the command is shown below:

Starting
 Obtaining SQL Servers Information ...
 Done
 Skipping Step 1 ...
 Executing Step 2 ...
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/cudb-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/identities-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/msc-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/csps-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/nph-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/auth-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ftest-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/avg-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/eps-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ims-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/sm-ds.sql on 10.22.23.5:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ldap-indexes-ds.sql on 10.22.23.5:15010
 ..ok
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/cudb-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/identities-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/msc-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/csps-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/nph-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/auth-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ftest-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/avg-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/eps-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ims-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/sm-ds.sql on 10.22.23.6:15010
 ..ok
 Applying /home/cudb/storageEngine/config/schema/ds/appSrv/ldap-indexes-ds.sql on 10.22.23.6:15010
 ..ok
 Done
 Finished

The requisites of using the command are as follows:

• Execute the command in the node where the PLDB master replica is located. For more information, refer to CUDB System Administrator Guide .

• cudbOperator users have no access to run this command.

• Format (1): Reallocate by moving DS entries from the source DSG: cudbReallocate -s | --source <dsgId> [-d | --destination <dsgId>] -p | --entriespercentage <number 1-100> [-o | --output <filepath>] [-D | --Debug] [-f | --force] [-n | --nthreads <number>]

• Format (2): Reallocate a list of elements to a specified destination: cudbReallocate -d | --destination <dsgId> -l | --list <filepath> [-o | --output] <filepath> [-D | --Debug] [-f | --force] [-n | --nthreads <number>]

• Format (3): Request the status of DSGs relevant to the reallocate command: cudbReallocate -u | --status [-D | --Debug]

• Format (4): Show command help message: cudbReallocate [-h | --help]

The following command options can be used:

• -u | --status: Prints the occupancy percentage and the memory level of all DSGs in the system. The memory occupation of the DSG is determined by the replica with the highest occupation. The possible status of the output are the following:

  • Below the eligible level.

  • Below the stop level.

  • Below the warning level.

  • Above the warning level.

  • Above the full level.

• -s | --source <dsgId> : Defines the source DSG with <dsgId> . The value of <dsgId> must be an integer between 1-255. Refer to CUDB Node Configuration Data Model Description for more information.

• -d | --destination <dsgId> : Defines the destination DSG on which entries are reallocated. The value of <dsgId> must be an integer between 1-255. If this command option is not used, then the command selects one or more suitable DSGs as reallocation targets automatically.

• -p | --entriespercentage <number 1-100> : Defines the percentage of the DS entries in the specific source DSG that is required to be moved away. The value must be an integer between 1-100.

• -l | --list: Defines the file containing the list of primary network identities which identify the DEs to reallocate. The file contains lines of strings with the following format: netIDType:= netIDValue. The file is case sensitive.

  Typical values of netIDType for common applications are as follows:

  • IMPI

  • IMPU

  • IMSI

  • IPADDRESS

  • MSISDN

  An example for these values is provided below:

  IMSI:=99999

  MSISDN:=100003

• -o | --output : Defines the output file where information on DE reallocation failures is stored. The default name of the output file is cudbReallocationResult <YYYY-MM-DD-HH24-MI>.txt, and is stored in the current directory. The file is deleted if the cudbReallocate command finishes without errors. The contents of the output file depend on whether the --list option was used when executing the command:

  • If the --list option was used when executing the command, the output file contains one line per failed network identity, with the following format:

    netIDType:= netIDValue; result <result>

    In the above example, the value of <result> can be as follows:

    • already moved, if the entry was already in the destination DSG.

    • invalid entry, if the specified network identity cannot be translated into a valid DE.

    • not moved, in case of any other faulty situation.

  • If the --list option was not used when executing the command, then each line in the output file states the DN of one of the DEs which could not be moved. If the DN was moved, but there was an error deleting it from the source DSG, an extra "moved"-suffix is added to the DN.

• -n | --nthreads: Restricted for Ericsson personnel.

• -D | --Debug: Restricted for Ericsson personnel.

• -f | --force: Forces reallocation if destination DSG is disabled for provisioning.

  • If destination DSG is specified and that DSG is disabled for provisioning, --force option allows reallocation over that DSG.

  • If destination DSG is not specified and one or more DSGs are disabled for provisioning, --force option allows reallocation over such DSGs.

• -h | --help: Displays command help message and exits.

The following list contains some example output messages:

• Reallocating from DSG <In case the reallocation command is triggered<id>> to DSG <id>.
  Reallocation is ongoing.
  Reallocation is ongoing, approximately 10% entries reallocated so far.
  ...
  Reallocation is finished. All entries reallocated.
  cudbReallocate: Success.

• Interrupt signal caught.
  Aborting reallocation process. Please wait...
  Reallocation terminated by user.

• Reallocating from DSG <id> to DSG <id>. 
  cudbReallocate: Partial Success. 
  Reallocate DSG <n> partially succeeded - unable to move some entries. 
  Consult output file for entries that could not be moved.

• Reallocating from DSG <id> to DSG <id>. 
  cudbReallocate: Partial Success. 
  Reallocate DSG <n> partially succeeded - All entries were not moved to destination DSG <y> 
  Refer to output file for details of failure entries where moved. 
  An entry of "already moved" indicates the entry is already in the destination DSG. 
  An entry of "invalid entry" indicates that the entry was not found or is not a primary network identity. 
  An entry of "not moved" indicates that could not be moved due to a temporary failure. 

• Reallocating from DSG <id> to DSG <id>. 
  cudbReallocate: Partial Success. 
  Reallocate DSG <n> partially succeeded - All entries were not moved to destination DSG <y> 
  No entries were moved to destination DSG <y>. 
  An entry of "already moved" indicates the entry is already in the destination DSG. 
  An entry of "invalid entry" indicates that the entry was not found or is not a primary network identity. 
  An entry of "not moved" indicates that could not be moved due to a temporary failure. 

• cudbReallocate: Failed. 
  Unexpected error. 

• cudbReallocate: Failed. 
  Invalid format: unrecognised option '<option>' 
  ...

• cudbReallocate: Failed. 
  Reconciliation is ongoing.

• cudbReallocate: Failed. 
  Source DSG <n> is not valid. 

• cudbReallocate: Failed. 
  Invalid format: Invalid DSG value, should be in range 1 - 255

• cudbReallocate: Failed. 
  The list <inputFile> could not be found or could not be opened.

• cudbReallocate: Failed. 
  The output <outputFile> already exists.

• cudbReallocate: Failed. 
  <outputFile> 
  Reallocate DSG <n> failed - DS master change detected in source DSG <y>.

• cudbReallocate: Failed. 
  <outputFile> 
  Reallocate DSG <x> failed - DS master change detected in destination DSG <y>.

• cudbReallocate: Failed. 
  <outputFile> 
  Reallocate DSG <n> failed - PLDB master change detected in destination.

• cudbReallocate: Failed. 
  <outputFile> 
  Reallocate DSG <n> failed - PLDB master change detected in destination.

• cudbReallocate: Failed. 
  Invalid format: Parameter [list] requires parameter [destination] 
  ...

• cudbReallocate: Failed. 
  Invalid format: Parameter [source] and parameter [list] are mutually exclusive 
  ...

• cudbReallocate: Failed. 
  Invalid format: Source and destination DSG IDs should not be identical 
  ...

• cudbReallocate: Failed. 
  PLDB master is not in the local node.

• cudbReallocate: Failed. 
  PLDB is not present in the local node.

• cudbReallocate: Failed. 
  CudbReallocate is already running.

• cudbReallocate: Failed. 
  The output <outputFile> file opening error.

• cudbReallocate: Failed. 
  Destination DSG <n> is not valid.

• cudbReallocate: Failed. 
  CudbReallocate is already running.

  Note:

  This output is displayed after an unexpected error in the command execution. This output is also displayed if reallocation is in process. If no other reallocation process is running, this output is displayed due to a previous reallocation process finished with an unexpected error. To unlock cudbReallocate for a particular DSG, use the following command: rm -rf /cluster/home/cudb/.lock.SC_2_?.cudbReallocate.DSG<x> x - the ID of the particular DSG Do not delete this file if the command is up and running, to prevent unexpected behaviors.

If destination DSG is blocked for provisioning, the example of output message is:

• Destination DSG 255 is blocked for reallocation.

cudbOperator users have no access to run this command.

• Format (1): cudbReconciliationMgr -c | --check <dsId>

• Format (2): cudbReconciliationMgr -a | --add <dsId>

• Format (3): cudbReconciliationMgr -l | --list

• Format (4): cudbReconciliationMgr [-h | --help]

The following command options can be used:

• -c | --check <dsId> : Checks if the DSG identified with <dsId> is in the Pending Task List.

• -a | --add: Adds a new pending reconciliation task for the DSG if the DS master is on the current CUDB node.

• -l | --list: Lists all pending tasks, that is, the contents of the Pending Task List.

• -h | --help: Displays command help message and exits. If the command is executed without options, the command use and help information is shown.

The command output is a log of the execution progress. The command result is provided at the end of the log.

The requisites of using the command are as follows:

• This command must be executed in all CUDB nodes.

• cudbOperator users have no access to run this command.

cudbRemoteTrust [-l | --local] [-a | --all [-p | --persistent]] [-b | --banner] [-h | --help]

The following command options can be used:

• -l | --local: Establishes the trust relationships in the current blade or VM of the CUDB node where the command is executed.

• -a | --all: Establishes the trust relationships in every blade or VM of the CUDB node where the command is executed.

• -p | --persistent: Stores the trust relationship settings in the following location:

  /home/cudb/common/config/sshTrust

  Note:

  This command option can be executed only if the --all option is also executed. This command option implies the execution of --banner option, too.

• -b | --banner: Disables legal warning banner for logins, targeting the local CUDB node over SSH, in case the source address of the SSH connection is a SITE_VIP from the CUDB_SITE network. For example, when an internal CUDB login is initiated from a remote node towards the local node.

  Note:

  This command option will also be executed when the --all --persistent combined options are executed.

• -h | --help: Displays command help message and exits.

Successful execution provides no output.

cudbOperator users have no access to run this command.

cudbResumeProvisioningNotification [-u | --user-facility <facility>] [-D |--debug] [-h |--help]

The following command options can be used:

• -u | --user-facility <facility> : Restricted for Ericsson personnel.

• -D | --debug: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

The command output is a log of the changes performed. The command result is provided at the end of the log.

The requisites of using the command are as follows:

• The partition must be in a system split situation of minority to accept this command.

• The command requires execution confirmation.

cudbServiceContinuity [-h |--help]

The following command option can be used:

• -h | --help: Displays command help message and exits.

The command can return the following output messages:

• In case of a minority system split situation, the command returns the following success message:

  cudbServiceContinuity 
  WARNING: This command will take all masters excluding PLDB in this partition! Are you sure you want to continue (y/n)? y
  The node /cudb/actions already existed
  Set in path: /cudb/actions  DATA: serviceContinuity
  Service Continuity successfully executed
  

• In case the execution of the command is not confirmed (n is selected instead of y), the command returns the following message:

  cudbServiceContinuity 
  WARNING: This command will take all masters excluding PLDB in this partition! Are you sure you want to continue (y/n)? n
  No action executed
  

• When executed with the -h or --help option, the command returns following output:

  cudbServiceContinuity -h
  ===================================================
                 USE of cudbserviceContinuity
  ===================================================
  Format : cudbserviceContinuity [-h | --help]
  Where:
                 -h | --help            Shows command usage and help

• In case of a majority system split situation, the command returns the following failure message:

  cudbServiceContinuity 
  WARNING: This command will take all masters excluding PLDB in this partition! Are you sure you want to continue (y/n)? y
  SC can not be set in a majority (majority[1, 2, 3] AR[] NS[])
  Command failed

• In case of a symmetrical split situation, the command returns the following failure message:

  cudbServiceContinuity 
  WARNING: This command will take all masters excluding PLDB in this partition! Are you sure you want to continue (y/n)? y
  SC can not be set in a evenSplit (evenSplit[2] AR[] NS[])
  Command failed
  

The requisites of using the command are as follows:

• cudbOperator users have no access to run this command.

• The command requires execution confirmation for some options.

• Format (1): cudbSwBackup [-c | --create <backup name>] [[-f | --force] -r | --restore <backup name>] [-d | --delete <backup name>] [-i | --info] [-l | --list] [-p | --print] [-h | --help]

• Format (2): cudbSwBackup -o | --delete-oldest -c | --create <backup name>

• Format (3): cudbSwBackup [--no-prompt] --restore <backup name>

• Format (4): cudbSwBackup -s | --schedule '<cron expression>'

• Format (5): cudbSwBackup -U | --Unschedule '<cron expression>'

The following command options can be used:

• -c | --create <backup name> : Creates a new CUDB software and configuration backup.

• -r | --restore <backup name> : Restores an already created CUDB software and configuration backup.

• --no-prompt: Restricted for Ericsson personnel.

• -d | --delete <backup name> : Deletes an already created CUDB software and configuration backup.

• -i | --info: Prints information about the CUDB and LDE backup location and file format.

• -l | --list: Lists the created CUDB software and configuration backups.

• -s | --schedule <cron expression> : Creates a periodic software and configuration backup according to the defined <cron expression> .

• -U | --Unschedule <cron expression> : Remove a periodic software and configuration backup according to the defined <cron expression> .

  Note:

  The format of the <cron expression> follows the standard UNIX cron expression format.

• -p | --print: Prints the information on the scheduled periodic software and configuration backup.

• -o|--delete-oldest: Removes the oldest backup without confirmation message, if more than 5 backups exist.

  Note:

  This option must be followed by the -c | --create option.

• -f | --force : Allows SW restore when the mysqlds of the PLDB are down (sql backup is not restored) or the CUDB node does not have one defined.

  Note:

  If the PLDB cluster is defined, is up, and replication is working after the LDE cluster reboot, restore the system monitor tables by executing the cudbApplyConfig -s init command. Otherwise, refer to the procedure in Storage Engine, Unable to Synchronize Cluster in PLDB, Major to get replication up and running and to restore the sql backup.

• -h | --help: Displays command help message and exits.

The output of the command is a log of the performed actions. An example output is provided below:

Pack and compress all directories and files under /home/cudb/* except swbackup, systemDataBackup and automatedBackupStorage directories.

IMM data persisted 
Obtaining SQL Servers Information ...
Creating tables backup into file /cluster/home/cudb/swbackup/newbackup-cudbSmpConfig.sql
Connecting to host 10.22.49.5:15000 , database: cudb_system_monitor
Let's tar the directory /cluster/home/cudb excluding backup directory itself /cluster/home/cudb/swbackup/

... 

Let's execute the lde-brf command: cluster brf create -l newbackup -t system -m newbackup
The resulting file is saved in /cluster/storage/no-backup/newbackup.tar 
Snapshot cleanup completed
newbackup/config.md5sum
newbackup/config.metadata
newbackup/config.tar.gz
newbackup/software.md5sum
newbackup/software.metadata newbackup/software.tar.gz
Backup successfully created.
The backup files: newbackup, are located in directories:
 /cluster/home/cudb/swbackup and
 /cluster/storage/no-backup

cudbOperator users have no access to run this command.

cudbSwVersionCheck [-p | --packages] [-c | --compare] [(-f | --reffile <REFFILE>) | (-d | --refdir <REFDIR>)] [-h | --help]

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -p | --packages: Prints package installation status.

• -c | --compare: Compares the package installation state to the cudbReference file and prints the differences, if there is any.

  Note:

  Omitting the -c and -p options has the same effect as using both of them.

• -f | --reffile <REFFILE> : Restricted for Ericsson personnel.

• -d | --refdir <REFDIR> : Restricted for Ericsson personnel.

An example output is provided below:

cudbOperator users have no access to run this command.

• Format (1): cudbSystemDataBackupAndRestore -c | --create [-F | --fast-copy] [-f | --forced] [-o | --copy-over-oam-vip] [-b | --cudbdatabackup-option <option_string>]

• Format (2): cudbSystemDataBackupAndRestore -c | --create -k | --keep-local [ -f | --forced ] [ -b | --cudbdatabackup-option <option_string>]

• Format (3): cudbSystemDataBackupAndRestore --restore <backup_path> [-F | --fast-copy] [-s | --cudbdatarestore-option <option_string>] [--no-prompt]

• Format (4): cudbSystemDataBackupAndRestore --restore-date <backup_date> [ -F | --fast-copy ] [ -f | --forced ] [ -s | --cudbdatarestore-option <option_string>] [--no-prompt]

• Format (5): cudbSystemDataBackupAndRestore -h | --help

The following command options can be used:

• -h | --help: Displays command help message and exits.

• -c | --create: Creates a system data backup.

• --restore <backup_path> : Restores a system data backup from the specified directory path.

• --restore-date <backup_date> : Restores a system data backup created on the defined date. The format of <backup_date> is YYYY-MM-DD_HH24-MI.

  Note:

  The --create, --restore and --restore-date options are mutually exclusive.

• --no-prompt: This command can be executed by Ericsson personnel only.

• -k | --keep-local: Forces to keep the backup files on the CUDB nodes where they are generated. If this option is used, the created backups will not be collected to the CUDB node where the command was ordered.

  Note:

  If -k | --keep-local is omitted, the generated backup files are collected to the CUDB node where the command was ordered, provided that there is enough storage space. The files are copied to the cluster area in the following directory: /home/cudb/automatedBackupStorage

• -F | --fast-copy: Disables the default SCP speed limit when copying backup files from one node to another.

  Note:

  Using this option yields a much higher network use.

• -f | --forced: Disables the checking of /home/cudb/systemDataBackup in case of backup creation or backup restore with the -R option. Furthermore, in case of backup creation, the checking of /home/cudb/automatedBackupStorage is disabled.

• -o | --copy-over-oam-vip: Transfer backup files over OAM_VIP address.

• -b | --cudbdatabackup-option <option_string> : Option arguments to pass to the cudbDataBackup command. The default value is -L.

• -s | --cudbdatarestore-option <option_string> : By default, -L is included, but it can be discarded. Additional options to use when doing a system data restore (cudbDataRestore parameters):

  • -T | --Timeout <seconds> : Restricted for Ericsson personnel.

  • -R | --Retries-number <number of retries> : Defines the number of retry attempts to establish the connection to the CUDB nodes where the specific DS Units or the PLDB must be restored. The default value is 2.

  • -S | --Script-path <script> : Defines the path where the post-restore commands are located. Do not use this option in a production environment.

  • -u | --user-facility <facility> : Enables Syslog facility for logging. Do not use this option in a production environment.

  • -L | --parallel-mode: Orders a restore for each CUDB node element (that is for the PLDB and all DS Units like DS1, DS2, and so on) at the same time instead of one after another (that is, not when the previous one is finished). The option does not guarantee that the restore takes place on the PLDB first, then on the DS Units in parallel.

  • -D | --Debug: Restricted for Ericsson personnel.

The following output examples are provided below:

• The below example output indicates normal operation:

  CUDB_44 SC_2_2# cudbSystemDataBackupAndRestore -c
  
  Checking /home/cudb/automatedBackupStorage on local node
  --------------------------------
  
  
          Local node: ... EMPTY
  
  Checking /home/cudb/systemDataBackup on nodes
  --------------------------------
  
  
          44: ... EMPTY
          43: ... EMPTY
  
  CREATE PART
  --------------------------------
  
  
  /home/cudb/systemDataBackup
  Listening for current PLDB and DSGs status reports (may take upto 2 minutes)
  Starting backup...
  Before calling pg_notification 
  BackupStart [INFO] - PS Notification trying stop notification was successfully sent.
  PS Notification successfully sent to : 172.31.233.139
  PS Notification failed to : NONE
  PS not notified : NONE
  
  cudb_backup     ver(1.3.4)
  
  BEGIN MANAGEMENT FOR LAST BACKUP
  Backup 2014-05-14_20-11 finished successfuly in :
  PLDB in CUDB node 44
      NDB node PL0
      NDB node PL1
      NDB node PL2
      NDB node PL3
  DSG#1 in CUDB node 43
      NDB node DS1_0
      NDB node DS1_1
  DSG#255 in CUDB node 43
      NDB node DS2_0
      NDB node DS2_1
  Attempting to de-block Provisioning Gateway. This may take up to a couple of minutes.
  
  COLLECT PART
  --------------------------------
  
  
          Copying backup piece from node 44 for dsg 0 for ndb node id 3 ... OK
          Copying backup piece from node 44 for dsg 0 for ndb node id 4 ... OK
          Copying backup piece from node 44 for dsg 0 for ndb node id 5 ... OK
          Copying backup piece from node 44 for dsg 0 for ndb node id 6 ... OK
          Copying backup piece from node 43 for dsg 1 for ndb node id 3 ... OK
          Copying backup piece from node 43 for dsg 1 for ndb node id 4 ... OK
          Copying backup piece from node 43 for dsg 255 for ndb node id 3 ... OK
          Copying backup piece from node 43 for dsg 255 for ndb node id 4 ... OK
  
  
  Please copy /home/cudb/automatedBackupStorage to a safe location to be able to restore the backup pieces when needed!
  
  
  
  ERROR SUMMARY
  --------------------------------
  
  
  None.
  

• The below example output shows an error caused by executing cudbSystemDataBackupAndRestore with the --restore option, while configuration changes are being applied:

  CUDB_210 SC_2_2# cudbSystemDataBackupAndRestore --restore /home/cudb/automatedBackupStorage
  
  VALIDATE PART
  --------------------------------
  
  
  NODE: 210
          DSG: 0
                  NDB: 3
                  NDB: 4
                  NDB: 5
                  NDB: 6
          DSG: 1
                  NDB: 3
                  NDB: 4
          DSG: 255
                  NDB: 3
                  NDB: 4
  
  DISTRIBUTE PART
  --------------------------------
  
  
  
  Creating /home/cudb/systemDataBackup on node 210
  
          Node 210 has DSG 0      -> copying ... id3-OK id4-OK id5-OK id6-OK
          Node 210 has DSG 1      -> copying ... id3-OK id4-OK
          Node 210 has DSG 255    -> copying ... id3-OK id4-OK
  Creating /home/cudb/systemDataBackup on node 244
  
          Node 244 has DSG 0      -> copying ... id3-OK id4-OK id5-OK id6-OK
          Node 244 has DSG 1      -> copying ... id3-OK id4-OK
          Node 244 has DSG 255    -> copying ... id3-OK id4-OK
  EXTRACT PART
  --------------------------------
  
  
          Node 210 has DSG 0      -> extracting ... id3-OK id4-OK id5-OK id6-OK
          Node 210 has DSG 1      -> extracting ... id3-OK id4-OK
          Node 210 has DSG 255    -> extracting ... id3-OK id4-OK
          Node 244 has DSG 0      -> extracting ... id3-OK id4-OK id5-OK id6-OK
          Node 244 has DSG 1      -> extracting ... id3-OK id4-OK
          Node 244 has DSG 255    -> extracting ... id3-OK id4-OK
  
  RESTORE PART
  --------------------------------
  
  
  Starting System Data Backup with command cudbDataRestore -B 2015-07-27_12-40 -L 2>&1 ...
  cudbDataRestore     ver(1.3.6)
  
  Trying for restore the backup from [2015-07-27_12-40] data files.
  
  Error executing the restore command in PL/DS node in CUDBNode#244
  Error executing the restore command in PL/DS node in CUDBNode210. Failed due parallel execution of cudbApplyConfig command.
  Check logs and cudbApplyConfig.lock file in /home/cudb/oam/configMgmt/commands/config directory!
  Restores process finished with error.
  
  
  
  ERROR: unable to restore backup
  
  
  ERROR SUMMARY
  --------------------------------
  
  
  
  ERROR: unable to restore backup
  WARNING: System data restoration will execute for the complete CUDB system with the data from the system backup. 
  Are you sure you want to continue (y/n)? y
  

• The below example output shows another error in another erroneous scenario:

  ERROR SUMMARY
  --------------------------------
  
  
  Unable to kickstart pl on node 24
  Unable to kickstart dsg 1 on node 24
  Unable to kickstart dsg 2 on node 24
  

This command can be accessed by cudbOperator user using sudo.

cudbSystemStatus [-a | --alarms] [-s | --sm-status] [-c | --cluster-status] [-C | --new-cluster-status] [-m | --check-mysql] [-p | --check-cudbprocess] [-b | --bc-status] [-B | --new-bc-status] [-r | --replication-status] [-R | --new-replication-status] [-t | --hardware-type] [-v | --version] [-h | --help]

The following command options can be used:

• -a | --alarms: Prints alarms.

• -b | --bc-status: Restricted for Ericsson personnel.

• -B | --new-bc-status: Prints the status of the BC process.

• -s | --sm-status: Prints the SM status.

• -c | --cluster-status: Restricted for Ericsson personnel.

• -C | --new-cluster-status: Prints cluster status.

• -m | --check-mysql: Checks database cluster server connections.

• -p | --check-cudbprocess: Checks CUDB processes relevant to the correct system behavior.

• -r | --replication-status: Restricted for Ericsson personnel.

  Attention!

  This command option is deprecated. Use the -R option instead.

• -R | --new-replication-status: Prints replication status. The possible output of the option for the DSGs are as follows:

  • M: Master

  • Sn: Slave - replication channel <#n> is active.

  • S?: Slave - Replication status is unknown.

  • [S]: Slave - replication channels are down.

  • Xm: Wrong state - masterless.

  • Xu: Wrong state - unreachable.

• -t | --hardware-type: Prints the value of the hwType attribute of each CUDB node and whether each DSG in the CUDB system is running on hybrid hardware (that is, whether the DS Units of a certain DSG are hosted on nodes with different hardware types). Refer to CUDB Node Configuration Data Model Description for more information about the hwType attribute.

• -v | --version: Prints the CUDB version.

• -h | --help: Displays command help message and exits.

The command shows information on the relevant system status. BC cluster information is showing status of the BC clusters in all the sites (unless the node is disabled, then the output is Disabled instead of showing the status of BC servers on that node), while SM information shows the status of the SM leader elected in every site.

If, for any reason, the BC cluster does not have the majority of BC servers, enough to work as a cluster, it is indicated in the output, and no SM leader appears on the affected site.

The requisites of using this command are as follows:

• The partition must be in a system split situation of minority or symmetrical split to accept this command.

• The command requires execution confirmation.

cudbTakeAllMasters [-h |--help]

The following command option can be used:

• -h | --help: Displays command help message and exits.

The command can return the following output messages:

• When executed with the -h or --help option, the command returns the following output:

  cudbTakeAllMasters -h
  ===================================================
  	USE of cudbTakeAllmasters
  ===================================================
  Format : cudbTakeAllmasters [-h | --help]
  
  Where:
  
  	-h | --help     	  Displays command help message and exits
  

• In case of a majority system split situation, the command may return the following failure message:

  cudbTakeAllMasters          
  WARNING: This command will take all masters in this partition! \
           Are you sure you want to continue (y/n)? y
  TAM can not be set in a majority (majority[1, 2] AR[] NS[])
  Command failed
  

The requisites of using the command are as follows:

• The command location must be included in the PATH system environment variable.

• cudbOperator users have no access to run this command.

• The command requires execution confirmation for some options.

• Format (1): cudbUnitDataBackupAndRestore (-p | --pl) (-n | --node) <nodeId> [(-f | --fast-copy)] [-q | --queued-copy] [-o | --copy-over-oam-vip] [--no-prompt]

• Format (2): cudbUnitDataBackupAndRestore (-d | --dsg) <dsgId> (-n | --node) <nodeId> [(-f | --fast-copy)] [-q | --queued-copy] [-o | --copy-over-oam-vip] [--no-prompt]

• Format (3): cudbUnitDataBackupAndRestore -h | --help

The following command options can be used:

• -p | --pl: Sets the PLDB cluster as the cluster to operate on. The command does not work, just exits with an error message, if any of the DS clusters in the node is the master replica of its data partition.

• -d | --dsg <dsgId> : Sets the DSG cluster defined with <dsgId> as the DSG cluster to operate on.

• -n | --node <nodeId> : Sets the slave node defined with the <nodeId> as the slave node on which the backup will be restored,

• -h | --help: Displays command help message and exits.

• -f | --fast-copy: Disables the default SCP speed limit when copying backup files from one node to another. Consider that this yields a much higher network use.

• -q | --queued-copy: Restricted for Ericsson personnel.

• -o | --copy-over-oam-vip: Transfer backup files over OAM_VIP address.

• --no-prompt: Restricted for Ericsson personnel.

An example output of the command is provided below:

The requisites of using the command are as follows:

• All previous configuration changes performed through the CUDB configuration CLI must be successfully applied on the node before executing the command.

• cudbOperator users have no access to run this command.

cudbUpdateUserInfo [-D | --Debug] [-h | --help] [-i | --internal]

The following command options can be used:

• -D | --Debug: Restricted for Ericsson personnel.

• -h | --help: Displays command help message and exits.

• -i | --internal: Restricted for Ericsson personnel.

The output informs about the success or failure of executing the command. An example output for each scenario is shown below:

• The output message of a successful execution must be similar to the below example:

  Success: User information successfully updated in node <nodeId>

• The output message of a failed execution must be similar to the below example:

  Failed. Unexpected error

The following command options can be used:

• -ps | --printPartitionStatus: Prints the current partition status.