6.11.3. Management and Monitoring of Cassandra Deployments

Monitoring a Cassandra replication scenario requires checking the status of both the master - extracting data from MySQL - and the slave which retrieves the remote THL information and applies it to Cassandra.

shell> trepctl status
Processing status command...
NAME                     VALUE
----                     -----
appliedLastEventId     : mysql-bin.000045:0000000000000505;-1
appliedLastSeqno       : 4861
appliedLatency         : 0.18
autoRecoveryEnabled    : false
autoRecoveryTotal      : 0
channels               : 1
clusterName            : alpha
currentEventId         : mysql-bin.000045:0000000000000505
currentTimeMillis      : 1499956897965
dataServerHost         : ubuntuheterosrc
extensions             : 
host                   : ubuntuheterosrc
latestEpochNumber      : 4806
masterConnectUri       : thl://localhost:/
masterListenUri        : thl://ubuntuheterosrc:2112/
maximumStoredSeqNo     : 4861
minimumStoredSeqNo     : 0
offlineRequests        : NONE
pendingError           : NONE
pendingErrorCode       : NONE
pendingErrorEventId    : NONE
pendingErrorSeqno      : -1
pendingExceptionMessage: NONE
pipelineSource         : jdbc:mysql:thin://ubuntuheterosrc:3306/tungsten_alpha?noPrepStmtCache=true
relativeLatency        : 1161.965
resourcePrecedence     : 99
rmiPort                : 10000
role                   : master
seqnoType              : java.lang.Long
serviceName            : alpha
serviceType            : local
simpleServiceName      : alpha
siteName               : default
sourceId               : ubuntuheterosrc
state                  : ONLINE
timeInStateSeconds     : 1868186.053
timezone               : GMT
transitioningTo        : 
uptimeSeconds          : 1868187.749
useSSLConnection       : false
version                : Tungsten Replicator 5.2.2 build 275
Finished status command...

On the slave, the output of trepctl shows the current sequence number and applier status:

shell> trepctl status
Processing status command...
NAME                     VALUE
----                     -----
appliedLastEventId     : mysql-bin.000045:0000000000000505;-1
appliedLastSeqno       : 4861
appliedLatency         : 0.0
autoRecoveryEnabled    : false
autoRecoveryTotal      : 0
channels               : 1
clusterName            : alpha
currentEventId         : NONE
currentTimeMillis      : 1499896056588
dataServerHost         : cassandra
extensions             : 
host                   : cassandra
latestEpochNumber      : 4806
masterConnectUri       : thl://ubuntuheterosrc:2112/
masterListenUri        : null
maximumStoredSeqNo     : 4861
minimumStoredSeqNo     : 0
offlineRequests        : NONE
pendingError           : NONE
pendingErrorCode       : NONE
pendingErrorEventId    : NONE
pendingErrorSeqno      : -1
pendingExceptionMessage: NONE
pipelineSource         : thl://ubuntuheterosrc:2112/
relativeLatency        : -59679.412
resourcePrecedence     : 99
rmiPort                : 25550
role                   : slave
seqnoType              : java.lang.Long
serviceName            : alpha
serviceType            : local
simpleServiceName      : alpha
siteName               : default
sourceId               : cassandra
state                  : ONLINE
timeInStateSeconds     : 1272.784
timezone               : GMT
transitioningTo        : 
uptimeSeconds          : 126394.304
useSSLConnection       : false
version                : Tungsten Replicator 5.2.2 build 275
Finished status command...

The appliedLastSeqno should match as normal. Because of the batching of transactions the appliedLatency may be much higher than a normal MySQL to MySQL replication.