USAGE for hms v1.0.32: hms show hms status {all|<instance>[:<component>]} [-o] hms {start|stop} <instance>[:<component>] hms dfm {on|off|status} <instance> hms {update|upgrade} <instance>[:<component>] hms failover <path> {i|h}:<instance_or_host> <style> hms [-h|-man|-V] DESCRIPTION: This is the Perforce Helix Management System, hms v1.0.32. This script is self-logging. That is, all output displayed on the screen (stdout and stderr) is simultaneously captured in a log file. You do not need to run this script with redirection operators like '> log' or '2>&1', and do not need to use 'tee.' The default log file is: /p4/hms/logs/hms.<NAME>.<DATESTAMP>.log HMS CONFIG FILES: The HMS config file defines a Helix global topology. HMS COMMANDS: status {all|<instance>[:<component>]} [-o] Get status of components defined in the Helix Topology file. Specify all for a site-wide global status, an instance name for all components related to a given instance or a specific component within an instance. start|stop <instance>[:<component>] Start or stop a specific component in the topology, or start/stop all components associated with a given instance. dfm {on|off|status} <instance> The 'dfm on' command puts all brokers for the specified SDP instance into "Down For Maintenance" mode. This involves stopping the broker running with the default config (p4_N.broker.cfg) and starting the broker using the DFM config file, p4_N.broker.dfm.cfg. The dfm broker config file is expected to be configured to reject all user commands and display a friendly message for users telling them that the Helix Server is offline for maintenance. The 'dfm off' command brings all brokers for the specified SDP instance (or all instances) back online with the default config, after shutting down brokers running with the dfm config. The 'dfm status' command checks the status of brokers running with the dfm config. update <instance>[:<component>] [-n] Update to the latest versions of software available for the current major release for the given component. An update will not upgrade to a new major version. Specify 'all' to perform a site-wide update of all defined Helix topology components. Updates are done one instance at a time. Update processing aborts in event of a failure to upgrade any component. Specify an instance name to update all components associated with a given Helix instance. Update processing aborts in event of a failure to update any component. The update processing varies depending on the component to be updated. It essentially consists of: 1. Stop the service. 2. Replace the executable (e.g .p4d, p4broker, Swarm files) to the latest patched executable. 3. Update SDP symlinks as needed. 4. Restart the service. For p4d, a database upgrade is not done, and no checkpoint processing occurs. For any given instance, updates occur in the proper order, with the master/commit server being updated last. In case of daisy chain of replicas, those farthest removed from the commit server are updated first. Use with the '-n' flag to see what versions would be updated. upgrade <instance>[:<component>] [-n] Upgrade to the latest versions of software available for the latest GA release, upgrading to new major versions if needed. Specify 'all' to perform a site-wide upgrade of all defined Helix topology components. upgrades are done one instance at a time. Upgrade processing aborts in event of a failure to upgrade or update any component. Specify an instance name to upgrade all components associated with a given Helix instance. Upgrade processing aborts in event of a failure to upgrade any component. The upgrade processing varies depending on the component to be upgraded. It essentially consists of: 1. Stop the service. 2. Replace the executable (e.g .p4d, p4broker, Swarm files) to the latest patched executable. 3. Restart the service. For p4d, an offline checkpoint is initiated at the start of processing. For any given instance, upgrades occur in the proper order, with the master/commit server being upgraded last. In case of a daisy chain of replicas, those farthest removed from the commit server are upgraded first. Use with the '-n' flag to see what versions would be updated or upgraded. failover <path> {h|i}:<scope> <style> [-n] Execute a failover using a pre-defined <path> name defined in the Helix Topology file. Multiple failover paths can be defined for a given SDP instance, defining (for example) a local failover option (using offline databases on the same host), an HA option, and one or more DR options. The <scope> must be prefixed with i: or h:, as in i:<SDPInstance> or h:<Hostname>. If an SDP instance is specified, that instance fails over to the designated backup host for the path selected. If a machine is specified, all instances currently mastered on that machine failover. In event of hardware failure of a host, this option should be considered. When a machine is specified for the scope, the <path> should be valid for all instances on that machine. Any instances for which the path is not valid will be skipped in the failover processing (but will not prevent it from handling other instances). The <style> is either 'scheduled' ('s' for short) or 'unscheduled' ('u' for short). This impacts how the failover process occurs. In a scheduled failover, all systems are expected to be operating normally at the start of the failover process, and the failover only occurs if all systems are operating normally. Scheduled failover can be used to take a perfectly working machine offline for a time, e.g. to add memory. An 'unscheduled' failover is executed in reaction to a problem of some kind, such as hardware failure. An 'unscheduled' failover should be used when it is known that master server is offline or otherwise not usable. If it can be reached, the master server is shutdown as part of an unscheduled failover. The 'failover' command can be abbreviated as 'fo'. HOST ALIAS UPDATE: External to processing of this script, the host alias used by users to taget the master server must be updated. This may involve a DNS change, virtual IP change, anycast update, etc. This must be done before the failover is complete and service can be restored for users. HMS GENERAL COMMAND OPTIONS (valid for all commands): -c <helix_topologoy_config> Specify the path to your hand-crafted Helix Topology configuration file. See documentation in the default config file regarding the required format for topology configuration. The default file is /p4/common/config/HelixTopology.cfg. Specify something like '-c /full/path/HelixTopology.cfg' or '-c HelixTopology.test.cfg'. With the latter example, the file is presumed to be in the /p4/common/config directory. The toplogy configuration file defines SDP Instances, Helix Topology Components, and Failover Options. This option is intended for development of changes to Helix Topology configuration files. HMS COMMAND OPTIONS (valid for certain commands as indicated): -o Specify '-o' to be optimistic regarding status of components for which status logic is not yet implememented. By default, components that don't yet have status logic coded report as failed. With '-o', components of known types report as OK. Components of unknown type always report as failed. This can be helpful in verifying whether the Helix Topology config file contains only valid/known component types. Components of unknown types should be commented out or marked as unmanaged. -n No-Op preview mode. This shows operations that would be performed, but takes no actions that affect the live system or data. This is valid only for command for which it is indicated. GENERAL LINE OPTIONS: -v<n> Set verbosity 1-5 (-v1 = quiet, -v5 = highest). -L <log> Specify the path to a log file, or the special value 'off' to disable logging. By default, all output (stdout and stderr) is captured in a log file named: /p4/hms/logs/hms.<NAME>.<DATESTAMP>.log -C Check the HMS config file and then stop. This can be used to verify the syntax of the HMS config file without starting an actual failover. -si Operate silently. All output (stdout and stderr) is redirected to the log only; no output appears on the terminal. This cannot be used with '-L off'. -D Set extreme debugging verbosity. -S Step mode - if running interactively prompt user to enter return before progressing to the next step. The '-S' option is not supported when called via p4broker (i.e. called as 'p4 hms' rather than calling the hms script directly). THIS FLAG IS NOT IMPLEMENTED AND WILL BE DEFERRED TO hms 2.0 or beyond. HELP OPTIONS: -h Display short help message -man Display man-style help message -V Dispay version info for this script and its libraries. GENERAL LINE OPTIONS: DEPENDENCIES: The bash shell must be installed as /usr/local/bin//bash, and should be bash 4.3 or higher, acquired from ftp.gnu.org. The bash in /bin/bash need only be bash 3.0+ or greater. EXAMPLES: Get a status in the master p4d for Instance 1: hms status 1:master Get a status in the second replica p4d for Instance 2: hms status 2:p4d-r02 Get a status for all known components, optimisitically assuming those we haven't coded status logic for yet are configured are happy: hms status all -o Show whether the second broker for Instance 2 can be updated to a newer patch version of p4broker, within the current major version: hms update 1:p4b02 -n Upgrade the second broker for Instance 2 to the latest patch version of p4broker, within the current major version: hms update 1:p4b02 Show what components in Instance 1 would be affected by site-wide topology upgrade: hms upgrade 1 -n Upgrade all components in Instance 1 in the correct order. hms upgrade 1 -n Perform an unscheduled failover for all instances mastered on host bos-helix-01: hms failover ha h:bos-helix-01 u Perform a scheduled failover for all instances mastered on host syd-helix-04: hms failover ha h:syd-helix-04 s Perform an unscheduled local failover for Instance 1 on its currently configured master host: hms failover local i:1 u
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#4 | 25550 | C. Thomas Tyler |
Split HMS from SDP, such that HMS will live on as a separate product, layered on the SDP. See: https://swarm.workshop.perforce.com/jobs/SDP-356 Many of the files deleted here have already been copied to HMS. See these HMS changes: https://swarm.workshop.perforce.com/changes/25531 https://swarm.workshop.perforce.com/changes/25533 And this branch spec: SDP_Split_2019.2_HMS In mkrep.sh, HMS-awareness is removed from mkrep.sh, a core SDP script, and the '-f' (Full Setup) flag has been temporarily removed. This useful functionality will be restored in an HMS script. This is a big change, so shellcheck v0.6.0 was implemented to support it. |
||
#3 | 21989 | C. Thomas Tyler |
Doc typo fixes only, no functional change. Bypassing pre-commit review. |
||
#2 | 21987 | Russell C. Jackson (Rusty) | Typo corrections. | ||
#1 | 21073 | C. Thomas Tyler | Naming convention tweak. | ||
//guest/perforce_software/sdp/dev/doc/hms_command_summary.txt | |||||
#1 | 21071 | C. Thomas Tyler | Added HMS command summary. |