Cluster Administration Scripts — Command Line Options

The scripts that can run on all servers in a MATRIXX Engine support the following command line options when they are initiated by the mtx user. Sometimes, the options are only valid for certain scripts. These cases are noted.

Syntax

script.py [-h] [--by_blade] [-d] [--debug_config_file_parsing] [--debug_function_calls] [--debug_output_formatting][--debug_threading_code] -e engineId -c clusterId [-p {0|1}] [--plain] [-skip_local] [--ssh_debug] [-u username] [ -w 0|1 -t seconds] 

Command Line Options

-h, --help
Help about the script options.
--by_blade
Init.d-based shutdown flag. When specified, the cluster is stopped by using OS-level /etc/init.d scripts to stop the servers one-by-one. The default stops the cluster by using a cluster management command, which causes the Cluster Manager to perform an orderly shut down of all servers at one time.
-d, --debug
Debug mode. When this option is set, more messages are displayed at the command line to help in debugging.
--debug_config_file_parsing
Debug flag for parsing the mtx_config.xml file. When specified, extra messages are printed to help in debugging the parsing of the mtx_config.xml file.
--debug_function_calls

Debug flag for function calls. When this option is specified, more messages are printed to help in debugging which functions call other functions.

--debug_output_formatting {0|1|2}
Debug flag for output formatting. When 0 is specified (default), no more messages are printed. When 1 is specified, more messages are printed to help in debugging the output formatting code. When 2 is specified, display lines are printed in hex format to help in debugging the output formatting code.
--d --debug_threading_code
Debug flag for threading code. When this option is specified, more messages are printed to help in debugging the threading code.
-e engineId, --engine=engineId
The MATRIXX Engine ID. If the MATRIXX Engine from which you are running the command is the target of the operation, you do not have to specify this option. You can specify an Engine ID using the -e engineId syntax or by specifying the engine number. For example, when running an engine script on engine ID 2, the following commands are equivalent:
  • start_engine.py
  • start_engine.py -e 2
  • start_engine.py 2
-c clusterId, --cluster=clusterId
The cluster on which to run the command. If the cluster from which you are running the command is the target of the operation, you do not have to specify this option. When not specified, the ${MTX_ENGINE_ID} and ${MTX_CLUSTER_ID} environment variables are used to determine the cluster.
You can specify a cluster ID using the -c clusterId syntax or by specifying the cluster number. When specifying the cluster number, you must also specify the engine number. For example, when running a cluster script on engine ID 2, cluster ID 2, the following commands are equivalent:
  • check_cluster.py
  • check_cluster.py -c 2
  • check_cluster.py 2:1

For more information about the MATRIXX environment variables, see the discussion about container directories and environment variables in MATRIXX Installation and Upgrade.

--no_fsck
If specified, no file system check is performed before mounting.
-p {0|1} --parallel {0|1}
Indicates whether the logical servers in the cluster is stopped, started, or restarted serially or in-parallel when the related script runs.
  • 0 – Stop the servers in serial mode, waiting for a logical server to stop before stopping the next one.
  • 1 – Stop the servers in parallel mode, not waiting for a logical server to stop before stopping the next one.

This option is valid only when the --by_blade option is specified.

--plain
Plain message display. When set, the script displays output messages without more information.
--skip_local
Skip mode. When used, the operation is not performed on the local server. The default is 0 (do not skip), which runs the script on all servers, including the local server.
--ssh_debug
If specified, the -v option is added to all ssh commands, which runs in verbose mode. This causes ssh to print debugging messages about its progress and is helpful in debugging connection, authentication, and configuration issues.
--skip_checkpointing
By default the specified command is run on the checkpointing server(s). If specified, this script is not run on the checkpointing server(s).
--skip_publishing
By default the specified command is run on the publishing server(s). If specified, this script is not run on the publishing server(s).
-u username, --as_user=username
When set, run the script as the specified user. The default is the current user.
-w {0|1}, --wait={0|1}
The wait mode for engine start and restart operations, which is only valid for the start_cluster.py and restart_cluster.py scripts.
  • 0 – Wait until the MATRIXX processes on a server are running before starting the next server in a cluster. This value does not wait for the cluster HA state to become ACTIVE or STANDBY before returning.
  • 1 – The default. Wait for the SNMP Cluster service state on each server to become ACTIVE then waits for the cluster HA state to become ACTIVE or STANDBY before returning.
This option is only valid with the start_cluster.py and restart_cluster.py scripts.
-t seconds, --timeout_in_seconds=seconds
This option is only valid when the --wait flag is set. The default is 120 seconds. Sets a timeout period that applies to each of these server start stages:
  • If this option is run on a publishing server cluster:
    • Starts the publishing server.
    • After the publishing cluster enters the INIT stage, this script starts monitoring database initialization. If database initialization stalls, this script starts the timeout period. If database initialization is still stalled when the timeout period ends, the script exits with an error.
    • Waits for the publishing cluster to reach an ACTIVE state.
  • If this option is run on a processing server cluster
    • Starts the processing servers in parallel.
    • After the processing cluster enters the INIT stage, this script starts monitoring database initialization. If database initialization stalls, this script starts the timeout period. If database initialization is still stalled when the timeout period ends, the script exits with an error.
    • Waits for the processing cluster to reach an ACTIVE or STANDBY state.
This option is only valid with the start_cluster.py and restart_cluster.py scripts.