Changing the status of a service is required either when the dataservice needs to be reconfigured, the topology altered, or when performing system maintenance.
The datasource status can be changed by using the datasource command, which accepts the datasource name and a sub-command:
datasource DATASOURCENAME SUBCOMMAND
For example, to shun the node host1
:
[LOGICAL:EXPERT] /alpha > datasource host1 shunFor detailed operations for different subcommands, see the following sections.
Shunning a datasource identifies the source as unavailable; a shunned Replica will not be used during a failover or switch operation.
Datasources can be automatically or manually shunned:
Automatic shunning occurs when the dataservice
is in AUTOMATIC policy
mode, and the datasource has become unresponsive or fails. For
example, when a Primary fails, an automatic switch to a new Primary is
performed, and the old Primary is shunned.
Manual shunning occurs when the shun command is given to a datasource. Manual shunning can be used to set a datasource into a state that allows for maintenance and management operations to be performed on the datasource.
To manually shun the datasource:
[LOGICAL:EXPERT] /alpha > datasource host3 shun
DataSource 'host3' set to SHUNNEDOnce shunned, the connector will stop using the datasource. The status can be checked using ls :
+----------------------------------------------------------------------------+ |host3(slave:SHUNNED(MANUALLY-SHUNNED), progress=157454, latency=1.000) | |STATUS [SHUNNED] [2013/05/14 05:24:41 PM BST] | +----------------------------------------------------------------------------+ | MANAGER(state=ONLINE) | | REPLICATOR(role=slave, master=host2, state=ONLINE) | | DATASERVER(state=ONLINE) | | CONNECTIONS(created=0, active=0) | +----------------------------------------------------------------------------+
Shunning a datasource does not stop the replicator; replication will continue on a shunned datasource until the replication service is explicitly placed into the offline state.
The level of the shunning is reported in the status as a manual operation. A manually shunned datasource can be enabled using the datasource recover command, see Section 6.3.6.2, “Recover a Datasource” .
The datasource recover command is a deeper operation that performs a number of operations to get the datasource back into the operational state. When used, the datasource recover command performs the following operations:
Restarts failed or stopped services
Changes the datasource configuration so that it is configured as a Primary or Replica. For example, an automatically failed Primary will be reconfigured to operate as a Replica to the current Primary.
Restarts the replicator service in the Replica or Primary role as appropriate
In all cases, the datasource recover command should be used if a datasource is offline or shunned, and it can be used at all times to get a datasource back in to operational state within the cluster. In essence, recover performs the same operations automatically as would be performed manually to get the node into the right state.
[LOGICAL:EXPERT] /alpha > datasource host3 recover
VERIFYING THAT WE CAN CONNECT TO DATA SERVER 'host3'
DATA SERVER 'host3' IS NOW AVAILABLE FOR CONNECTIONS
RECOVERING 'host3@alpha' TO A SLAVE USING 'host1@alpha' AS THE MASTER
DataSource 'host3' is now OFFLINE
RECOVERY OF 'host3@alpha' WAS SUCCESSFULDuring the recovery process, the node will be checked, replication reconfigured, and the node brought back in to active service. If this process fails because the databases and replication states are out of sync and cannot be recovered, Tungsten Cluster may advise that a backup of another datasource and recovery to this datasource is performed. For more information on restoring from backups, see Section 6.11, “Restoring a Backup” .
A datasource can be explicitly placed into offline mode. In offline
mode, client applications connections to datasources are paused. When
switching to OFFLINE mode existing
connections are given a five-second grace period to complete their
operations before being forced to disconnect. Replicator operation is
not affected.
To set a datasource offline:
[LOGICAL:EXPERT] /alpha > datasource host3 offline
DataSource 'host3@alpha' is now OFFLINE
If the dataservice is in
AUTOMATIC policy mode, and
there are no other faults in the datasource, it will automatically be
placed into ONLINE mode. To set a
datasource offline the dataservice must be in
MAINTENANCE or
MANUAL policy modes.
standby datasources receive
replication data, but are not part of the load-balancing provided by
Tungsten Connector. In the event of a failover situation, a
standby datasource will be
enabled within the cluster as a Replica. Because the
standby datasource is up to date
with respect to the replication of data, this process is instantaneous.
The connector will be updated, and the new Replica will operate as a
read-only datasource.
To configure a datasource as a
standby:
[LOGICAL:EXPERT] /alpha > datasource host3 standby
Datasource 'host3' now has role 'standby'
To clear the standby state:
[LOGICAL:EXPERT] /alpha > datasource host3 clear standby
Datasource 'host3' now has role 'slave'When a Replica goes into standby mode, it will finish running any SQL queries that were started before it went into standby mode. New queries, even on the same connection, will not be directed to a Replica that has just gone into standby
An archive datasource receives
replication data and is included as part of the load-balancing provided
by Tungsten Connector. It is excluded from failover switches and will not
be used as a Primary in the event of a failure. To mark a datasource as
an archive datasource:
[LOGICAL:EXPERT] /alpha > datasource host3 set archiveTo remove the archive role:
[LOGICAL:EXPERT] /alpha > datasource host3 clear archiveThe archive role is a temporary requirement, and will not survive a re-install or upgrade.