Engine 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] [-d] [--debug_config_file_parsing] [--debug_function_calls] [--debug_output_formatting][--debug_threading_code] -e engineId [-p {0|1}] [--plain] [-s seconds] [--skip_local] [--ssh_debug] [--sync_time_in_seconds seconds] [-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 individually, starting with the processing servers, and then the publishing servers. 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.
--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
-p {0|1} --parallel {0|1}
Indicates whether the logical servers in the engine 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.
-s seconds, --sync_time_in_seconds=seconds
The amount of time the standby engine can fall behind and for which database synchronization still occurs. Normally, switchover might not proceed if replay to the standby engine falls behind by 2 seconds or more. However, in slower environments, more delay might be acceptable. Use the '-s' option to overwrite the default value (2 seconds) to ensure switchover succeeds.
--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.
-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_engine.py and restart_engine.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_engine.py and restart_engine.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 engine start stages:
  • This script starts the publishing server and waits for the publishing cluster to reach a START state.
  • It starts all 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.
  • Waits for the publishing cluster to reach an ACTIVE state.
This option is only valid with the start_engine.py and restart_engine.py scripts.