Provision Hot Standby Node | Teradata Vantage on AWS (DIY) - 2.2 - Provisioning Hot Standby Nodes after Deployment - Teradata Vantage on AWS

Teradata Vantageā„¢ on AWS (DIY) Installation and Administration Guide

Teradata Vantage on AWS
Release Number
Release Date
May 2021
Content Type
Publication ID
English (United States)
Use this procedure for the following use cases:
  • If you want to provision HSNs after deploying an instance. For this use case, no changes to your auto scaling permissions are required.
  • If you deployed an instance prior to Teradata Vantage on AWS (DIY) 5.02, performed a software upgrade, and want to provision HSNs. For this use case, ask your IAM administrator to grant you the following permissions as a new auto scaling group is created as part of this procedure:
    • autoscaling:CreateAutoScalingGroup
    • autoscaling:CreateLaunchConfiguration
    • autoscaling:DeleteLaunchConfiguration
There is a higher risk of failure when provisioning HSNs after deployment. Resource issues sometimes prevent AWS from provisioning resources. AWS retries provisioning automatically until successful.
  1. From a database node, determine if any HSNs are currently configured.
    # tdc-hot-standby --hsn-status
  2. Provision up to two HSNs.
    # tdc-hot-standby -m n
    where n is the number of HSNs you want to provision.
  3. Get status as the HSNs are launched and configured.
    # tdc-hot-standby --hsn-status
  4. If the image is out of date or the instance type of the HSNs is different than the instance type of the node, update the HSNs.
    # tdc-hot-standby -u
    The auto scaling group is updated accordingly.
  5. [Optional] Confirm the HSNs are up to date.
    # tdc-hot-standby --hsn-status

    After provisioning HSNs, you do not need to stop and restart the database.

  6. If resource issues are preventing AWS from provisioning resources for the HSNs and you want to back out of the process, stop the AWS provisioning process.
    # tdc-hot-standby -m 0
    Teradata recommends not backing out of this process as there is no cost associated until the HSNs are provisioned.
You can monitor the provisioning process from the EC2 console.
  • HSNs are all named stack name-hsn on deployment. For example, if the stack name is mydbs, the HSNs are named mydbs-hsn.
  • From the Tags tab, you can identify the HSN with a key of HSN and a value that represents the status. The status initially displays Configuring.
  • The status changes to Ready when the HSN is ready for use.
  • When a node fails, the HSN attaches to the failed node and the status of the HSN changes to In-Use.
  • Another HSN automatically deploys to replace the HSN that was put in use. It sits idle and does not go into service until another node fails.