Common Reference

Generated Field Reference

When using any of the tools within Tungsten status information is output using a common set of fields that describe different status information. These field names and terms are constant throughout all of the different tools. A description of each of these different fields is provided below.

99 of 99

Option	Description
`accessFailures`
`active`
`activeSeqno`
`appliedLastEventId`	Event ID of the last event applied (Replica) or generated (Primary)
`appliedLastGoodLatency`	The last know latency prior to the replicator going offline.
`appliedLastGoodSeqno`	Sequence number of the last confirmed event applied (Replica) or generated (Primary).
`appliedLastSeqno`	Sequence number of the last event applied (Replica) or generated (Primary)
`appliedLatency`	Latency between when the source event was extracted and the event applied.
`applier.class`	Classname of the current applier engine
`applier.name`	Name of the current applier engine
`applying`	The applying field show the current seqno being applied.
`applyTime`
`autoRecoveryEnabled`	Indicates whether autorecovery has been enabled.
`autoRecoveryTotal`	Number of times the replicator has used autorecovery since it was started.
`averageBlockSize`
`blockCommitRowCount`
`cancelled`
`channel`	Number of applier channels used to apply data.
`clusterName`	Composite cluster name or service name of this service
`commits`
`committedMinSeqno`
`criticalPartition`
`currentBlockSize`
`currentEventId`	Event ID of the transaction currently being processed
`currentLastEventId`
`currentLastFragno`
`currentLastSeqno`
`currentTimeMillis`	Current time in milliseconds
`dataServerHost`
`discardCount`
`doChecksum`
`estimatedOfflineInterval`
`eventCount`
`extensions`
`extractor.class`
`extractTime`
`filter.#.class`
`filter.#.name`
`filterTime`
`flushIntervalMillis`
`fsyncOnFlush`
`headSeqno`
`intervalGuard`
`lastCommittedBlockSize`	The size of the last block that was committed as part of the block commit procedure.
`lastCommittedBlockTime`	The duration since the last committed block.
`latestEpochNumber`
`logConnectionTimeout`
`logDir`
`logFileRetainMillis`
`logFileSize`
`masterConnectUri`	The URI being used to extract THL information
`masterListenUri`	The URI on which the replicator is listening,
`maxChannel`
`maxDelayInterval`
`maximumStoredSeqNo`	The maximum transaction ID that has been stored locally on the machine in the TH
`maxOfflineInterval`
`maxSize`
`minimumStoredSeqNo`	The minimum transaction ID stored locally in the THL on the host
`name`
`offlineRequests`	Contains the specifications of one or more future offline events that have been configured for the replicator.
`otherTime`
`pendingError`
`pendingErrorCode`
`pendingErrorEventId`
`pendingErrorSeqno`	The sequence number where the current error was identified
`pendingExceptionMessage`	The current error message that caused the current replicator offline
`pipelineSource`	The source for data for the current pipeline.
`processedMinSeqno`
`queues`
`readOnly`
`relativeLatency`	The latency between now and the timestamp of the last event written to the stored THL
`resourcePrecedence`
`rmiPort`
`role`	The current role of the host in the corresponding service specification.
`seqnoType`	The internal class used to store the transaction ID
`serializationCount`
`serialized`
`serviceName`	The name of the configured service
`serviceType`	The configured service type
`shard_id`
`simpleServiceName`	A simplified version of the `serviceName`.
`siteName`
`sourceId`
`stage`
`started`
`state`
`stopRequested`
`store.#`
`storeClass`
`syncInterval`
`taskCount`
`taskId`
`timeInCurrentEvent`	Shows the time processing the current event
`timeInStateSeconds`
`timeoutMillis`
`totalAssignments`
`transitioningTo`
`uptimeSeconds`	Shows in seconds, how long the component has been running.
`version`	Shows the current version of the Software running.

A C L M O P R S T U V

A terminology options

`appliedLastEventId`

The event ID from the source database of the last corresponding event from the stage that has been applied to the database. When extracting, the output from trepctl shows the MySQL binary log file and the byte position within the log where the transaction was extracted:

shell> trepctl status
Processing status command...
NAME                     VALUE
----                     -----
appliedLastEventId     : mysql-bin.000064:0000000002757461;0
...

`appliedLastGoodLatency`

Version	`6.1.16`

If the replicator is in an offline or error state, the appliedLatency will show a value of -1. This property will reflect the last known applied latency prior to the offline event. When the service is online, this will reflect the same values as appliedLatency. The value is written to disk every 10 secs so as not to overload the replicator. This can be adjusted by setting the following property svc-applier-last-applied-write-interval=20

`appliedLastGoodSeqno`

Version	`6.1.16`

If the replicator is in an offline or error state, the appliedLastSeqno will show a value of -1. This property will reflect the last known applied seqno prior to the offline event. When the service is online, this will reflect the same values as appliedLastSeqno. The value is written to disk every 10 secs so as not to overload the replicator. This can be adjusted by setting the following property svc-applier-last-applied-write-interval=20

`appliedLastSeqno`

The last sequence number for the transaction from the Tungsten stage that has been applied to the database. This indicates the last actual transaction information written into the Replica database.

appliedLastSeqno       : 212

When using parallel replication, this parameter returns the minimum applied sequence number among all the channels applying data.

`appliedLatency`

The appliedLatency is the latency between the commit time of the source event and the time the last committed transaction reached the end of the corresponding pipeline within the replicator. Within a Primary, this indicates the latency between the transaction commit time and when it was written to the THL. In a Replica, it indicates the latency between the commit time on the Primary database and when the transaction has been committed to the destination database. Clocks must be synchronized across hosts for this information to be accurate.

appliedLatency         : 0.828

The latency is measure in seconds. Increasing latency may indicate that the destination database is unable to keep up with the transactions from the Primary. In replicators that are operating with parallel apply, appliedLatency indicates the latency of the trailing channel. Because the parallel apply mechanism does not update all channels simultaneously, the figure shown may trail significantly from the actual latency.

`applier.class`

Classname of the current applier engine

`applier.name`

Name of the current applier engine

`applying`

Version	`8.0.0`

}...
applying               : 3 / 0 (92.86%)
...

In the above example, the applier is processing seqno 3 / fragno 0 and already applied 92.86% (this represents a percentage of rows and statements that were already applied). When parallel apply in enabled, there will be one applying field per channel configured, for example the following shows 2 channels:

...
applying.0             : 
applying.1             : 25 / 0 (92.86%)
...

`autoRecoveryEnabled`

Indicates whether autorecovery has been enabled by setting the auto-recover-max-attempts propertyy. The field indicates the value as either true or false accordingly.

`autoRecoveryTotal`

A count of the number of times the replicator has used autorecovery to go back online since the replicator was started. This can be used to determine if autorecovery has been used. More details on autorecovery can be found in the trepsvc.log file. The counter is reset when the replicator determines that the replicator has successfully gone online after an autorecovery.

C terminology options

`channel`

The number of channels being used to apply transactions to the target dataserver. In a standard replication setup there is typically only one channel. When parallel replication is in effect, there will be more than one channel used to apply transactions.

channels               : 1

`clusterName`

The name of the cluster. This information is different to the service name and is used to identify the cluster, rather than the individual service information being output.

`currentEventId`

Event ID of the transaction currently being processed

`currentTimeMillis`

The current time on the host, in milliseconds since the epoch. This information can used to confirm that the time on different hosts is within a suitable limit. Internally, the information is used to record the time when transactions are applied, and may therefore the appliedLatency figure.

L terminology options

`lastCommittedBlockSize`

The lastCommittedBlockSize contains the size of the last block that was committed as part of the block commit procedure. The value is only displayed on appliers and defines the number of events in the last block. By comparing this value to the configured block commit size, the commit type can be determined. For more information, see "Tungsten Replicator Block Commit and Memory Usage".

`lastCommittedBlockTime`

The lastCommittedBlockSize contains the duration since the last committed block. The value is only displayed on appliers and defines the number of seconds since the last block was committed. By comparing this value to the configured block interval, the commit type can be determined. For more information, see "Tungsten Replicator Block Commit and Memory Usage".

M terminology options

`masterConnectUri`

The URI being used to extract THL information. On a Primary, the information may be empty, or may contain the reference to the underlying extractor source where information is being read. On a Replica, the URI indicates the host from which THL data is being read:

masterConnectUri       : thl://host1:2112/

In a secure installation where SSL is being used to exchange data, the URI protocol will be thls:

masterConnectUri        : thls://host1:2112/

`masterListenUri`

The URI on which the replicator is listening for incoming Replica requests. On a Primary, this is the URI used to distribute THL information.

masterListenUri        : thls://host1:2112/

`maximumStoredSeqNo`

The maximum transaction ID that has been stored locally on the machine in the THL. Because Tungsten Replicator operates in stages, it is sometimes important to compare the sequence and latency between information being ready from the source into the THL, and then from the THL into the database. You can compare this value to the appliedLastSeqno, which indicates the last sequence committed to the database. The information is provided at a resolution of milliseconds.

maximumStoredSeqNo     : 25

`minimumStoredSeqNo`

The minimum transaction ID stored locally in the THL on the host.

minimumStoredSeqNo     : 0

The figure should match the lowest transaction ID as output by the thl index command. On a busy host, or one where the THL information has been purged, the figure will show the corresponding transaction ID as stored in the THL.

O terminology options

`offlineRequests`

Contains the specifications of one or more future offline events that have been configured for the replicator. Multiple events are separated by a semicolon:

shell> trepctl status
...
inimumStoredSeqNo     : 0
offlineRequests        :  Offline at sequence number: 5262;Offline at time: 2025-01-26 00:00:00 EST
pendingError           : NONE

P terminology options

`pendingErrorSeqno`

The sequence number where the current error was identified

`pendingExceptionMessage`

The current error message that caused the current replicator offline

`pipelineSource`

The source for data for the current pipeline. On a Primary, the pipeline source is the database that the Primary is connected to and extracting data from. Within a Replica, the pipeline source is the Primary replicator that is providing THL data.

R terminology options

`relativeLatency`

The relativeLatency is the latency between now and timestamp of the last event written into the local THL. This information gives an indication of how fresh the incoming THL information is. On a Primary, it indicates whether the Primary is keeping up with transactions generated on the Primary database. On a Replica, it indicates how up to date the THL read from the Primary is. A large value can either indicate that the database is not busy, that a large transaction is currently being read from the source database, or from the Primary replicator, or that the replicator has stalled for some reason. An increasing relativeLatency on the Replica may indicate that the replicator may have stalled and stopped applying changes to the dataserver.

`role`

The current role of the host in the corresponding service specification.

S terminology options

`seqnoType`

The internal class used to store the transaction ID. In MySQL replication, the sequence number is typically stored internally as a Java Long (java.lang.Long). In heterogeneous replication environments, the type used may be different to match the required information from the source database.

`serviceName`

The name of the configured service, as defined when the deployment was first created through tpm.

serviceName            : alpha

A replicator may support multiple services. The information is output to confirm the service information being displayed.

`serviceType`

The configured service type. Where the replicator is on the same host as the database, the service is considered to be local. When reading or write to a remote dataserver, the service is remote.

`simpleServiceName`

A simplified version of the serviceName.

T terminology options

`timeInCurrentEvent`

Shows the time that the replicator has been processing the current event. When processing very large transactions this can be used to determine whether the replicator has stalled or is still actively extracting or applying the information.

U terminology options

`uptimeSeconds`

Shows in seconds, how long the component has been running.

V terminology options

`version`

Shows the current version of the Software running.