Routing Behavior Summary | Teradata Unity - 17.00 - Routing Behavior Summary - Continuous Availability - Teradata Unity

Teradata® Unity™ User Guide

Product
Continuous Availability
Teradata Unity
Release Number
17.00
Published
September 2020
Language
English (United States)
Last Update
2020-09-15
dita:mapPath
fmz1594836948704.ditamap
dita:ditavalPath
qqk1595871525984.ditaval

Unity routes requests by request type (Read, Write, or Read/Write) or by connection type (Balanced, Default, Preferred, or Passive).

Routing by Request Type

The following table shows how various types of requests are routed in sessions that are managed (associated with a managed Routing Rule). For passive sessions, all queries go directly and exclusively to the single system where the session is open.

Request Type Routing Rule Types
Read Specifies how Read requests are routed across Teradata systems. Default, Preferred, and Create Routing-Preferred.
Write Specifies which systems are involved in processing Write requests for a session. Default, Create Preferred, and Create Balanced.
Read/Write Specifies how Read and Write requests are routed for a session. Default and Preferred.

Routing by Connection Type

Session routing determines how Read and Write requests are routed from the client application or user to Teradata Database systems. This table shows routing behaviors based on connection type.

Connection Type Session Source To Add Routing Rule Routing Behavior
BALANCED:

User connection, as defined in user mapping, connects to multiple systems that are load balanced for optimum performance.

  • Supported for Write session routing only.
  • Unity connects the client to all Teradata systems identified by the user mapping and routing rule.
  • If logon fails, log entry is created.
  • An error returns to the application only when all logons fail.
  • Active sessions are connections to the load-balanced Teradata system.
  • Other connections are passive until failover occurs.
  • Specify two or more Teradata systems.
  • Specify "Balanced" to set load balancing for Write requests to systems.
  • First system name in list cannot start with a wildcard (*).
  • Failover is possible.
  • Active sessions are constantly changing based on load balancing requirements.
  • Failover occurs on errors only if the error code profile setting is "Fail over".
  • Exit occurs on errors only if the error code profile setting is "Exit".
If CREATE ROUTING - BALANCED routing is selected:
  • Request submitted only to the designated system for the session.
  • If request fails, the request is submitted to the next system on the Write list in a valid state.
  • All systems in the list are tried until the session request is successfully processed.
  • Read list must contain all systems in the Write list.
DEFAULT:

User connection that matches the defined user mapping, connects to any system defined by the Default routing rule.

Used by Unity when a routing rule is not specified for the userid in the user mapping.

  • Supported for both Read and Write requests.
  • For any user, Unity connects to all Teradata systems specified by the Default routing rule.
  • If logon fails, a log entry is created. An error is returned to the application only when all logons fail.
  • Users are logged on to the Teradata system defined in the Default routing rule.
  • Select the DefaultRouting routing rule when associating user mappings with default routing behavior.
  • Used if there is no user mapping for the userid.
  • Failover and Exit are possible and occur as defined by the Default routing rule.
PREFERRED:
User connection, as defined in user mapping, connects to
  • Single named Teradata system, or
  • Multiple systems in a preferred order.
Options are:
  • Read Preferred
  • Create Routing Preferred
  • Supported for both Read and Write requests.
  • Unity connects the client to all Teradata systems identified by the user mapping and routing rule.
  • An error returns to the application only when all logons fail.
  • Active session is the connection to the preferred Teradata system.
  • For single system for routing both Read and Write requests, specify one Teradata system.
  • For multiple systems in a preferred order, specify two or more Teradata systems.
  • First system name in list cannot start with a wildcard (*).
  • Select Preferred to indicate that the order of Teradata systems in the list is relevant to routing operations.
  • Prioritize order of systems to determine failover order.
  • Associate user mappings with the Preferred routing rule.
  • No failover occurs for single named Teradata systems, and errors are returned to the application.
  • Failover is possible in a multiple system configuration.
  • Active sessions fail over to the next Teradata system specified in the routing rule system list.
  • Failover occurs on errors only if the error code profile setting is "Fail over".
  • Exit occurs on errors only if the error code profile setting is "Exit".
If CREATE ROUTING - PREFERRED routing is selected:
  • Request submitted to the first system on the WRITE list that is in a valid state.
  • If request fails, the request is submitted to the next system on the WRITE list in a valid state.
  • Sessions to the Teradata systems are closed after all pending requests are processed by the system.
  • Read list must contain all systems in the Write list.
If both Read Preferred and Create Routing Preferred options are specified, the system lists must be identical, Moving or failing over data requires that the new preferred system be able to apply the rules of both the Read Preferred and Create Write Preferred routing.
REJECT LOGON:

Connections from the specified user are rejected by Unity.

Sessions are not allowed, and the connection is rejected.

Not applicable Not applicable
PASSIVE:

User connection matches a User Mapping, as defined in the associated passive routing rule. This rule is used to open a connection to a single system.

  • Supported for all clients that only want to read/write data to one system
  • Unity connects the client to one system only
  • If a logon fails, other systems in the routing rule (if any) are tried. Logon failures are returned to the user if no systems can establish a session.
  • Select Passive when adding the Routing Rule on the Session Routing tab, or specify "Passive" as the keyword before the routing rule name with the unityadmin commands.
  • Prioritize the order of systems to determine failover order (* not supported for systems; user must specify all systems by name).
  • All Reads and Writes go to the system where the session is opened, by-passing the Unity Data Dictionary.
  • No locking/sequencing is performed, and sessions are excluded from Unity's Failover and Recovery.
  • If a request fails and the error code matches a Failover error code, the session is fully closed and moved to the new system automatically. This occurs even when the session was in the middle of an explicit transaction (after Failover, a new explicit transaction is not started and only the query is retried).
Unity also allows for manual Failover of a session.