Failover Usage Notes | High Availability | Teradata Data Mover - Usage Notes - Teradata Data Mover

Teradata® Data Mover User Guide

Product
Teradata Data Mover
Release Number
17.00
Published
November 30, 2021
Language
English (United States)
Last Update
2021-11-04
dita:mapPath
gmn1574692806523.ditamap
dita:ditavalPath
cjo1509024828169.ditaval
dita:id
B035-4101
lifecycle
previous
Product Category
Analytical Ecosystem

You can use host names or IP addresses as values in failover.properties. The following table describes what happens in certain scenarios when using the automatic failover feature:

Scenario Result
The default password for dmuser has been changed on any of the servers specified in failover.properties. SSH setup fails, which prevents the active-standby components from starting correctly.
Invalid host names are specified in failover.properties. The SSH setup fails.
Config is run as a user other than ROOT. The SSH setup fails.
The dm.rest.endpoint is not modified in commandline.properties. The command line is not able to connect to a standby REST server when the active REST server goes down.
The broker.url is not modified in daemon.properties and agent.properties. The daemon and agent are not able to connect to a standby JMS broker when the active JMS broker goes down.
The master.host and master.port values in sync.properties are not set correctly on both active and standby sync servers. The sync service does not start correctly.
The standby sync service goes down after failover has been enabled. The updates on the active server are applied to the standby server when the standby sync service is restarted using the /opt/teradata/datamover/sync/nn.nn/dmsync startslave command.
The active sync service goes down after failover monitoring has been enabled. A warning message displays in the monitor log on the monitoring server. Any updates that occurred on the active server when the active sync service was down are not sent to the standby. The active sync service can be restarted in active mode using the dmcluster setmaster command from the active daemon server.
Both daemon servers go down after failover monitoring has been enabled. The monitoring service detects the active daemon server failure and initiates a failover sequence on the standby daemon server. If it is unable to connect to the standby daemon server, it exits and the components need to be restarted using the dmcluster setmaster command from the active daemon server once the servers are up.
A active daemon goes down and a failover has been initiated. The daemon is restarted again using the dmdaemon service script. The monitoring service notices two daemon running and stop the daemon on the server that is not the current active. To properly restore the daemon that went down, use the dmcluser setmaster command.

For more information, see Failing Back to the Old-Restored Active Daemon.

A standby daemon is started using the dmdaemon service script when the active daemon is still running. The monitoring service notices two daemons running and stops the daemon on the server that is not the current active. To properly set the components in standby mode, use the dmcluster setmaster command from the active daemon server.
The JMS broker on the active daemon server goes down. Failover occurs.
ActiveMQ on the standby daemon starts. Failover shuts down the service automatically. To properly switch between the active and standby servers, use the dmcluster setmaster command.