6.10.1. Using Multiple Dataservices

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

  1. 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 Section 3.4, “Deploying Tungsten Connector Only” if you want the host to be fully independent.

  2. Update the dataservices.properties file in /opt/continuent/tungsten/cluster-home/conf. Add a line for each new master/slave cluster the connector will connect to. Keep this file updated as you add and remove servers from each cluster.


    Do not list composite dataservices in this file. The connector will automatically discover those from the managers in each cluster.

  3. Restart the connector. Any users connected to this connector will be disconnected at this time.

    shell > connector restart
  4. Update the user.map to list new users for each new dataservice. See Section 6.6, “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.

    Version Support: 6.0.3

    The read affinity setting now supports multiple dataservices with ordering and exclusion (only one was previously allowed).

    You may now 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 QOS RO_RELAXED is in use.

      The affinity feature routes both reads and writes when using a Multimaster 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:


      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:


    See Section 6.6.1, “user.map File Format” for more details.

    In 6.0.4 and later, the effect of affinity during cluster chnges has been updated to support 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 now 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.

    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 to tpm.

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.