Controls the role of the server that a connection ends up being connected to. Used in high-availability, read-only scale-out, and cloud configurations. Depending on the setting, the connection may be redirected to another server, including providing load balancing.
Read-only scale-out and database mirroring each require a separate license. See Separately licensed components.
Syntax{ NodeType | NODE }={ DIRECT | PRIMARY | MIRROR | COPY | READONLY} UsageNetwork server only.
Allowed valuesDIRECT This is the default setting when connecting to a non-cloud database server.
When the NodeType connection parameter is set to DIRECT, the database server accepts the connection without performing load balancing or redirection.
PRIMARY This is the default setting when connecting to a cloud server.
If the NodeType connection parameter is set to PRIMARY and you have connected to the primary server, the connection is accepted. If you have connected to a non-primary server (such as, the mirror server, a copy node, or any other cloud database server), the database server redirects the connection to the primary server.
When connecting to a cloud server this NodeType, do not specify the ServerName connection parameter.
COPY When the NodeType connection parameter is set to COPY, the database server performs load balancing and chooses a copy node. In the cloud, the copy node is chosen at random. In a non-cloud read-only scale-out system, the database server examines the copy nodes in its own branch (including itself if it is not the root node) and chooses the copy node with the lightest load. If the database server does not choose itself, it redirects the client to the chosen database server.
When connecting to a cloud server with this NodeType, do not specify the ServerName connection parameter.
MIRROR If the NodeType connection parameter is set to MIRROR and you have connected to the mirror server, the connection is accepted. If you have connected to the non-mirror server, the database server redirects the connection to the mirror server.
When connecting to a cloud server with this NodeType, do not specify the ServerName connection parameter.
READONLY When the NodeType connection parameter is set to READONLY, you are connected to any read-only server, either a copy node or the mirror. If there are no copy nodes, this is equivalent to the MIRROR setting. If there are copy nodes, this is equivalent to the COPY setting.
When connecting to a cloud server with this NodeType, do not specify the ServerName connection parameter.
DefaultDIRECT (non-cloud database server)
PRIMARY (cloud database server)
RemarksThis connection parameter is used by client applications to control the role of the server they connect to, as well as to do load balancing among database servers involved in read-only scale-out. Clients specify this connection parameter to indicate what type of database server they want to connect to. The database server that the client initially connects to determines which database server should handle the connection, and if necessary, redirects the connection to the appropriate database server by returning the address of the database server. The client is automatically disconnected from the original database server, and then automatically connects to the appropriate database server.
Using NodeType with non-cloud database servers When you specify COPY, the load balancing occurs on the branch that contains the database server the client initially connected to. A branch consists of that database server and any of its children. This feature can be useful for performing load balancing among geographically separate servers.
If a client connection is redirected to a different database server, the value specified in the ServerName (Server) connection parameter and the value of the Name database server property do not match. See Name server property.
When NodeType is specified, the application typically connects to the root node, and that database server determines which copy node is least heavily loaded. The connection is then redirected to that copy node. If the application makes and drops several such connections within a short period of time, the connection is pooled and the root node is not asked which copy server to use. Using connection pooling reduces the load on the root node, but may not give expected behavior. The application can specify that its connections cannot be pooled to ensure that the root server determines which copy node to connect on each connection.
If you are using this parameter to redirect connections that use Kerberos authentication or integrated logins all the database servers in the scale-out tree must be configured as follows:
Integrated logins All of the database servers in the scale-out tree must be a part of the same Windows user group or be configured to allow the same Windows users to access them.
Kerberos authentication All of the database servers in the scale-out tree must have Kerberos authentication enabled. The Kerberos server principal for all the servers in the scale-out tree must have the same realm.
See also ExampleThe primary and mirror servers are located in Waterloo, Ontario. Clients running in Japan may want to set up a group of copy nodes in Japan to reduce connection latency. If a branch of copy nodes in Japan was a direct child of the root node, then other children could be added beneath the copy node in Japan. Clients would connect to the hub and specify NodeType=COPY. Japanese local, read-only connections would then be load-balanced among the local database servers, and no client would ever connect to database servers elsewhere. If a client needed to make changes to the database, they would change their connection string to use NodeType=PRIMARY.
To connect to the read-write database named joey running in a cloud database configuration, where kangaroo1 and kangaroo2 are two hosts running cloud servers, you could use the following connection parameters:
UID=rick;PWD=secret;DBN=joey;Host=kangaroo1,kangaroo2 |
To connect to any read-only database named joey running in a cloud database configuration, where kangaroo1 and kangaroo2 are two hosts running cloud servers, you could use the following connection parameters:
UID=rick;PWD=secret;DBN=joey;Host=kangaroo1,kangaroo2;NodeType=READONLY |
 |
Discuss this page in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |