Tungsten Clustering

Using Multiple Dataservices

The connector is able to work with multiple dataservices. It may be a combination of Primary/Replica or composite dataservices. The connector will communicate with managers in each dataservice and provide connectivity.

Configure the host as a connector for one of the dataservices. This will be the default dataservice for the connector. Any version upgrades for this cluster will also upgrade the connector. See "Deploying a Standalone Tungsten Connector" if you want the host to be fully independent.
Update the dataservices.properties file in /opt/continuent/tungsten/cluster-home/conf. Add a line for each new Primary/Replica cluster the connector will connect to. Keep this file updated as you add and remove servers from each cluster.
Important
Do not list composite dataservices in this file. The connector will automatically discover those from the managers in each cluster.
Restart the connector. Any users connected to this connector will be disconnected at this time.
```
shell > connector restart
```
Update the user.map to list new users for each new dataservice. See "User Authentication" for more details. Specifically, the user.map may not include multiple users with the same name but different dataservices. Create unique users in each dataservice before updating user.map.
The read affinity setting supports multiple dataservices with ordering and exclusion.
You may fine-tune the affinity by specifying an ordered list of dataservice names.
- affinity is defined as the host (single cluster only) or dataservice (composite clusters) to prefer for reads when RO_RELAXED is in use.
  The affinity feature routes both reads and writes when using a Composite Active/Active topology.
- This can be handled per user in user.map, globally via the tpm option connector-affinity, or via the connection string.
- The affinity string is an ordered list of dataservice names, separated by commas, where the first dataservice entry will be the one used by default. If the first dataservice in the list is not available, the connector will use the next one listed, and so forth.
- Dataservices not specified in the list, if any, will be used last and randomly.
- It is also possible to exclude one or more dataservices by adding a hyphen ("-") in front of the dataservice name.
- The deployment used in the examples below consists of a composite dataservice global, with four member dataservices (i.e. one cluster per site): east, west, north and south.
  Just for reference, this is the user definition syntax in the user.map file:
```
{User} {Password} {DataServiceName-or-CompositeDataServiceName} [Affinity]
```
  For example, to exclude site south from servicing read request in user.map:
```
sales secret global east,west,north,-south
```
  To do the same globally via the tpm command, use the following configuration setting:
```
connector-affinity=east,west,north,-south
```
  The above affinity string "east,west,north,-south" will try east, then west, then north. If none of the first three are available, a connection request would not succeed since south has been excluded by the negation ("-").
  In the following user.map example, dataservices north and south would be available as random candidates if the first two (east and west) were unavailable:
```
sales secret global east,west
```
  To do the same globally via the tpm command, use the following configuration setting:
```
connector-affinity=east,west
```
See "user.map File Format" for more details.
Affinity during cluster changes supports reconnection when the correct datasource becomes available.
When a site goes offline, connections to this site will be forced closed. Those connections will reconnect, as long as the site stays offline, they will be connected to remote site.
You can enable an option so that when the site comes back online, the connector will disconnect all these connections that couldn't get to their preferred site so that they will then reconnect to the expected site with the appropriate affinity.
Note that this only applies to bridge mode. In proxy mode, relevancy of connected data source will be re-evaluated before every transaction.
When not enabled, connections will continue to use the server originally configured until they disconnect through normal attribution. This is the default option.
To enable forced reconnection, use the connector-reset-when-affinity-back=true option in your configuration.

The connector is now ready to accept users for each of the new dataservices. Keep the dataservices.properties and user.map files updated to make sure the connector works properly.