sgc-backupsgc-backup-prunesgc-installsgc-node-startsgc-node-stopsgc-preparesgc-revert-abortsgc-revert-clustersgc-revert-completesgc-revert-nodesgc-revert-rollbacksgc-revert-startsgc-statussgc-upgrade-abortsgc-upgrade-clustersgc-upgrade-completesgc-upgrade-nodesgc-upgrade-rollbacksgc-upgrade-start
Upgrade related commands:
-
sgc-upgrade-cluster— performs a complete cluster upgrade in a single command -
sgc-upgrade-start— starts the upgrade process -
sgc-upgrade-node— upgrades the specified node(s) -
sgc-upgrade-complete— completes the upgrade process -
sgc-upgrade-abort— aborts the upgrade process -
sgc-upgrade-rollback— rolls back an in-progress upgrade
Reversion related commands:
-
sgc-revert-cluster— performs a complete cluster reversion in a single command -
sgc-revert-start— starts the reversion process -
sgc-revert-node— reverts the specified node(s) -
sgc-revert-complete— completes the reversion process -
sgc-revert-abort— aborts the reversion process -
sgc-revert-rollback— rolls back an in-progress reversion
Maintenance:
-
sgc-install— installs an SGC node or nodes from a given OCSS7 installation package -
sgc-prepare— prepares an SGC node or nodes for upgrade or reversion -
sgc-backup— creates a backup of an SGC node or nodes essential configuration data -
sgc-backup-prune— prunes the number of SGC backups on a host -
sgc-node-start— starts an SGC node or nodes -
sgc-node-stop— stops an SGC node or nodes -
sgc-status— displays a summary of the status of SGC clusters and nodes on the given hosts
sgc-backup
Create a backup of an SGC installation’s critical configuration files. This is not a full backup and should not replace a rigorous backup regime.
Example Usage
To backup the entire example cluster:
$ ./orca -H vm1,vm2,vm3 sgc-backup --cluster PC1 --nodes PC1-1,PC1-2,PC1-3
To create a backup of just PC1-1 and its version 3.0.0.0 installation:
$ ./orca -H vm1 sgc-backup --cluster PC1 --nodes PC1-1 --version 3.0.0.0
To backup all nodes belonging to only cluster installed on vm2:
$ ./orca -H vm2 sgc-backup
sgc-backup-prune
Remove all but the most recent x backups from the specified cluster, node(s) and version.
Example Usage
To leave just the default number of backups for each node in the example cluster:
$ ./orca -H vm1,vm2,vm3 sgc-backup-prune --cluster PC1 --nodes PC1-1,PC1-2,PC1-3
To remove all backups from nodes PC1-1 and PC1-3 in the example cluster:
$ ./orca -H vm1,vm3 sgc-backup-prune --cluster PC1 --nodes PC1-1,PC1-3 --retain 0
sgc-install
Creates a new SGC installation with a minimal configuration.
The installation has the following parameters set in SGC.properties:
-
hazelcast.group -
ss7.instance
The default hazelcast.xml is installed, with backup-count set to the value provided by the --backup-count parameter.
All other parameters and configuration files are set to the default values.
|
|
sgc-install is only used to create a completely new SGC installation. To prepare an upgraded SGC instance for an online upgrade see sgc-prepare.
|
Mandatory Parameters
-
--cluster— the name of the cluster that the new node(s) belong to -
--nodes— the name of the new nodes -
One of the following parameters must be supplied:
-
--package-directory— the path to thepackagesdirectory from an Orca SGC upgrade bundle containing apackages.cfgfile. -
--sgc-package— the local path to the SGC installation package
-
Optional Parameters
-
--backup-count— the value to be used forbackup-countinhazelcast.xml. If unspecifiedbackup-countwill be set to one less than the number of nodes provided in the--nodesargument, or to one if only one node is provided. -
--overwrite— overwrite any existing SGC installation at the target location. Default behaviour is to return an error if an installation already exists with this cluster, node and version.
|
|
The default value of backup-count should only be used if the entire cluster is installed in a single sgc-install operation.
In all other cases this value should be manually specified to be one less than the final cluster size.
|
Example Usage
To install the entire example cluster (cluster=PC1, nodes=PC1-1,PC1-2 and PC1-3) from scratch using OCSS7 3.0.0.1:
$ ./orca -H vm1,vm2,vm3 sgc-install --cluster PC1 --nodes PC1-1,PC1-2,PC1-3 --sgc-package /path/to/ocss7-3.0.0.1.zip
Or to install just node PC1-1 into cluster PC1 that will eventually contain 3 nodes:
$ ./orca -H vm1,vm2,vm3 sgc-install --cluster PC1 --nodes PC1-1 --sgc-package /path/to/ocss7-3.0.0.1-zip --backup-count 2
|
|
The backup-count in hazelcast.xml can be altered manually later if required.
Doing so requires a cluster restart if the cluster is running.
|
sgc-node-start
Starts one or more SGC nodes.
This command pauses for 120s after starting each node to allow the node to join the SGC cluster and complete data redistribution.
Optional Parameters
-
--cluster— the cluster containing the node(s) to start -
--nodes— the nodes in the cluster to apply this operation to. If unspecified the nodes will be auto-detected. -
--ignore-state— do not perform the pre-checks associated with this operation
sgc-node-stop
Stops one or more SGC nodes.
Optional Parameters
-
--cluster— the cluster containing the node(s) to stop -
--nodes— the nodes in the cluster to apply this operation to. If unspecified the nodes will be auto-detected. -
--ignore-state— do not perform the pre-checks associated with this operation
sgc-prepare
Creates one or more new SGC installations and copies configuration from the existing active SGC instance(s) of the same nodes and cluster to the new installation.
sgc-prepare is typically used over sgc-install when performing an online upgrade from an older to a newer SGC version.
Mandatory Parameters
-
--package-directory— the path to thepackagesdirectory from an Orca SGC upgrade bundle containing apackages.cfgfile. -
--sgc-package— the local path to the SGC installation package
Optional Parameters
-
--cluster— the name of the cluster that the new node(s) belong to -
One of the following parameters must be supplied:
-
--nodes— the nodes in the cluster to apply this operation to. If unspecified the nodes will be auto-detected. -
--overwrite— overwrite any existing SGC installation at the target location. Default behaviour is to return an error if an installation already exists with this cluster, node and version.
Example Usage
To prepare OCSS7 3.0.0.1 for the entire example cluster:
$ ./orca -H vm1,vm2,vm3 sgc-prepare --cluster PC1 --nodes PC1-1,PC1-2,PC1-3 --sgc-package /path/to/ocss7-3.0.0.1.zip
To re-run the prepare operation for just node PC1-3 in the example cluster:
$ ./orca -H vm3 sgc-prepare --cluster PC1 --nodes PC1-3 --sgc-package /path/to/ocss7-3.0.0.1.zip --overwrite
sgc-revert-abort
Aborts an in-progress SGC reversion.
Pre-requisites:
-
The cluster must be in
REVERT_MULTI_VERSIONmode. -
All cluster members must be running the version of the SGC that was running prior to
sgc-revert-startcommand being issued. -
At least one cluster member must be running.
Once complete the SGC cluster will be in NORMAL mode.
sgc-revert-cluster
Performs a complete SGC revert from the current version to the specified older version in a single command.
This command performs the operations of the following commands:
-
sgc-prepare— if the--sgc-packageargument is given
Pre-requisites:
-
The cluster must be in
NORMALmode. -
All cluster members must be specified using the
--nodesparameter. -
All cluster members must be running.
-
(Optional) If
--target-versionis specified, the target installation must exist on all nodes.
The reversion process takes several minutes per node.
Once completed, the cluster will be running the version specified with either --sgc-package or --target-version and be in NORMAL mode.
Mandatory Parameters
-
One of the following parameters must be specified:
-
--package-directory— the path to thepackagesdirectory from an Orca SGC upgrade bundle containing apackages.cfgfile. -
--sgc-package— the local path to the SGC installation package. -
--target-version— the pre-installed target version to upgrade to.
-
Optional Parameters
-
--nodes— the nodes in the cluster to apply this operation to. If unspecified the nodes will be auto-detected. -
--overwrite— overwrite any existing installation when the--sgc-packageargument is provided.
Example Usage
To revert the cluster from version 3.0.0.1 to a pre-installed 3.0.0.0 version:
orca -Hvm1,vm3,vm2 sgc-revert-cluster --cluster PC1 --target-version 3.0.0.0
Or to revert the cluster from version 3.0.0.1 to a non-existent 3.0.0.0 version:
orca -Hvm1,vm2,vm3 sgc-revert-cluster --cluster PC1 --sgc-package /path/to/ocss7-3.0.0.0.zip
sgc-revert-complete
sgc-revert-node
Stops the specified nodes, replaces them with the older SGC installation, and starts the replacement node(s).
Pre-requisites:
-
The cluster must be in
REVERT_MULTI_VERSIONmode. -
The nodes to be reverted must have a pre-prepared installation of the target version available.
-
The target version must be older than the current version.
-
All cluster members must be running.
If multiple nodes are to be reverted these will be processed one at a time, with a pause in between reversions. This wait period is necessary to allow time for the reverted node to rejoin the cluster and for the cluster to repartition itself.
Mandatory Parameters
-
--target-version— the target version to revert to
Example Usage
To revert the whole example cluster from OCSS7 3.0.0.1 to OCSS7 3.0.0.0:
$ ./orca -H vm1,vm2,vm3 sgc-revert-node --cluster PC1 --target-version 3.0.0.0
To revert just node PC1-2 in the example cluster:
$ ./orca -H vm2 sgc-revert-node --cluster PC1 --nodes PC1-2 --target-version 3.0.0.0
sgc-revert-rollback
Rolls back an in-progress SGC reversion, reinstating the specified SGC version.
|
|
The user must take care to ensure that the specified version is the original version prior to the revert. The revert process does not 'remember' the previous version. |
By default the rollback process is performed one node at a time to minimise the chance of service loss.
If the --hard parameter is specified the entire cluster will be stopped, rolled back, and then restarted.
This will result in a service outage.
Once complete the SGC cluster will be running the specified SGC version and be operating in NORMAL mode.
Mandatory Parameters
-
--target-version— the original SGC version to rollback to
sgc-revert-start
Starts the SGC reversion process.
Once completed the cluster will be in REVERT_MULTI_VERSION mode.
Mandatory Parameters
-
--target-version— the target SGC version to revert to. This SGC version must already be installed and configured.
sgc-status
sgc-upgrade-abort
Aborts an in-progress SGC upgrade.
Pre-requisites:
-
The cluster must be in
UPGRADE_MULTI_VERSIONmode. -
All cluster members must be running a version of the SGC whose native data format is equal to the current native format of the cluster.
-
At least one cluster member must be running.
Once complete the SGC cluster will be in NORMAL mode.
sgc-upgrade-cluster
Performs a complete SGC upgrade from the current version to the specified target version in a single command.
This command performs the operations of the following commands:
-
sgc-prepare— if the--sgc-packageargument is given
Pre-requisites:
-
The cluster must be in
NORMALmode. -
All cluster members must be specified using the
--nodesparameter. -
All cluster members must be running.
-
(Optional) If
--target-versionis specified, the target installation must exist on all nodes.
The upgrade process takes several minutes per node.
Once completed, the cluster will be running the version specified with either --sgc-package or --target-version and be in NORMAL mode.
Mandatory Parameters
-
--ignore-state— do not perform the sanity checks associated with the node stopping and starting parts of this operation -
One of the following parameters must be specified:
-
--package-directory— the path to thepackagesdirectory from an Orca SGC upgrade bundle containing apackages.cfgfile. -
--sgc-package— the local path to the SGC installation package. -
--target-version— the pre-installed target version to upgrade to.
-
Optional Parameters
-
--cluster— the cluster to start the upgrade on -
--nodes— the nodes in the cluster to apply this operation to. If unspecified the nodes will be auto-detected. -
--overwrite— overwrite any existing installation when the--sgc-packageargument is provided.
Example Usage
To upgrade the cluster PC1 from current version 3.0.0.0 to 3.0.0.1 using the Orca SGC upgrade package.
This will install the new 3.0.0.1 nodes and copy the configuration from the existing nodes:
orca -Hvm1,vm3,vm2 sgc-upgrade-cluster --cluster PC1 --package-directory packages/
To upgrade the cluster PC1 from version 3.0.0.0 to 3.0.0.1 using the standalone OCSS7 installation ZIP file.
This will install the new 3.0.0.1 nodes and copy the configuration from the existing nodes.
orca -Hvm3,vm2,vm1 sgc-upgrade-cluster --cluster PC1 --sgc-package /path/to/ocss7-3.0.0.1.zip
Alternatively, to upgrade the cluster PC1 from version 3.0.0.0 to a pre-installed and pre-configured version 3.0.0.1:
orca -Hvm1,vm2,vm3 sgc-upgrade-cluster --cluster PC1 --target-version 3.0.0.1
sgc-upgrade-complete
sgc-upgrade-node
Stops the specified nodes, replaces them with the pre-prepared upgraded SGC installation, and starts the replacement node(s).
Pre-requisites:
-
The cluster must be in
UPGRADE_MULTI_VERSIONmode. -
The nodes to be upgraded must have a pre-prepared installation of the target version available.
-
The target version must be newer than the current version.
-
All cluster members must be running.
If multiple nodes are to be upgraded these will be processed one at a time, with a wait in between upgrades. This wait period is necessary to allow time for the upgraded node to rejoin the cluster and for the cluster to repartition itself.
Mandatory Parameters
-
--target-version— the target version to upgrade to
Example Usage
To upgrade the whole example cluster from OCSS7 3.0.0.0 to OCSS7 3.0.0.1:
$ ./orca -H vm1,vm2,vm3 sgc-upgrade-node --cluster PC1 --target-version 3.0.0.1
To upgrade just node PC1-2 in the example cluster:
$ ./orca -H vm2 sgc-upgrade-node --cluster PC1 --nodes PC1-2 --target-version 3.0.0.1
sgc-upgrade-rollback
Rolls back an in-progress SGC upgrade, reinstating the specified SGC version.
|
|
The user must take care to ensure that the specified version is the original version prior to the upgrade. The upgrade process does not 'remember' the previous version. |
By default the rollback process is performed one node at a time to minimise the chance of service loss.
If the --hard parameter is specified the entire cluster will be stopped, rolled back, and then restarted.
This will result in a service outage.
Once complete the SGC cluster will be running the specified SGC version and be operating in NORMAL mode.
Mandatory Parameters
-
--target-version— the original SGC version to rollback to
sgc-upgrade-start
Begin the SGC upgrade process.
Pre-requisites:
-
The cluster must be in
NORMALmode. -
All cluster members must be specified using the
--nodesparameter. -
At least one cluster member must be running.
-
One backup matching the current SGC configuration must have been taken using the
sgc-backupcommand.
Once complete the SGC cluster will be in UPGRADE_MULTI_VERSION mode.
