Switching From Slave Mode to Master Mode - Teradata Data Mover

Teradata Data Mover User Guide

Product
Teradata Data Mover
Release Number
16.00
Published
December 2016
Language
English (United States)
Last Update
2018-03-29
dita:mapPath
rdo1467305237457.ditamap
dita:ditavalPath
ft:empty
dita:id
B035-4101
lifecycle
previous
Product Category
Analytical Ecosystem
Running the master and slave synchronization services allows you to use the daemon on the slave server to continue running jobs when the daemon on the master fails. Because these services keep the repositories on the master and slave servers synchronized, the slave server is used as the failover.
Name Description
Original-master The system primarily used as the master system before failover occurred. Also referred to as the failed master or restored master, depending on the state of the system.
Designated-slave The slave system assigned to take responsibility as the master system if the original-master stops working. Also referred to as the designated new master.
Slave-only A slave system that remains as a slave in case of failure, unlike the designated-slave, which becomes the master during failure. Multiple slave-only systems my be present.
  1. Wait for the designated-slave synchronization service to finish executing all the SQL statements on the slave server. This can be confirmed by waiting a few minutes and then checking if the dmSyncSlave.json file is being regenerated. Upon failure in the slave synchronization system, this file might not get removed.
  2. If the designated-slave's synchronization system is still running, stop the service on the server by running, /opt/teradata/datamover/sync/nn.nn/dmsync stop, where nn.nn refers to the major and minor version numbers of Data Mover .
  3. On the designated-slave, edit the sync.properties file and set sync.isMaster to true, so the designated-slave acts as the master server.
  4. Remove the following files if they exist in the log directory.
    • dmSyncMaster.json
    • slave_.<clientName>lastread
    • dmSyncSlave.json
    • slave_sql.lastExecuted
  5. Run /opt/teradata/datamover/sync/nn.nn/dmsync start to start the master synchronization service for the new designated master server (designated-slave).
    Where nn.nn in the path refers to the major and minor version numbers of Data Mover.
  6. Run /opt/teradata/datamover/sync/nn.nn/dmsync stop for any remaining slave-only servers that are synchronized with the failed original-master.
    Where nn.nn in the path refers to the major and minor version numbers of Data Mover.
  7. For each of the remaining slave-only systems, edit the value of master.host in sync.properties to reflect the host name of the designated new master server (designated-slave).
  8. Run /etc/init.d/dmdaemon start to restart the daemon on the designated new master server (designated-slave).
  9. Enable the synchronization service on the designated-slave while it serves as the master system during failure by running the teradata/datamover/sync/nn.nn/dmsync start command.
    Where nn.nn in the path refers to the major and minor version numbers of Data Mover.
    For more information, see Starting the Synchronization Service.
  10. Run /opt/teradata/datamover/sync/nn.nn/dmsync start for the remaining slave-only servers to restart the synchronization service.
    Where nn.nn in the path refers to the major and minor version numbers of Data Mover.
  11. On the machine on which the command-line interface is installed, enter a new value for broker.url in commandline.properties to reflect the host name or IP address of the designated-slave.
  12. If you have the Data Mover portlet installed in your environment, click Data Mover Setup in the Admin menu in the Teradata Viewpoint portal to enable monitoring of the designated-slave Data Mover server.