sgc-backup
sgc-backup-prune
sgc-install
sgc-node-start
sgc-node-stop
sgc-prepare
sgc-revert-abort
sgc-revert-cluster
sgc-revert-complete
sgc-revert-node
sgc-revert-rollback
sgc-revert-start
sgc-status
sgc-upgrade-abort
sgc-upgrade-cluster
sgc-upgrade-complete
sgc-upgrade-node
sgc-upgrade-rollback
sgc-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 thepackages
directory from an Orca SGC upgrade bundle containing apackages.cfg
file. -
--sgc-package
— the local path to the SGC installation package
-
Optional Parameters
-
--backup-count
— the value to be used forbackup-count
inhazelcast.xml
. If unspecifiedbackup-count
will be set to one less than the number of nodes provided in the--nodes
argument, 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 thepackages
directory from an Orca SGC upgrade bundle containing apackages.cfg
file. -
--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_VERSION
mode. -
All cluster members must be running the version of the SGC that was running prior to
sgc-revert-start
command 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-package
argument is given
Pre-requisites:
-
The cluster must be in
NORMAL
mode. -
All cluster members must be specified using the
--nodes
parameter. -
All cluster members must be running.
-
(Optional) If
--target-version
is 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 thepackages
directory from an Orca SGC upgrade bundle containing apackages.cfg
file. -
--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-package
argument 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_VERSION
mode. -
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_VERSION
mode. -
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-package
argument is given
Pre-requisites:
-
The cluster must be in
NORMAL
mode. -
All cluster members must be specified using the
--nodes
parameter. -
All cluster members must be running.
-
(Optional) If
--target-version
is 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 thepackages
directory from an Orca SGC upgrade bundle containing apackages.cfg
file. -
--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-package
argument 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_VERSION
mode. -
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
NORMAL
mode. -
All cluster members must be specified using the
--nodes
parameter. -
At least one cluster member must be running.
-
One backup matching the current SGC configuration must have been taken using the
sgc-backup
command.
Once complete the SGC cluster will be in UPGRADE_MULTI_VERSION
mode.