7.6.1. user.map File Format

The current user.map file is located within the tungsten-connector/conf directory within an active installation. The file should be synchronized across all the servers within a dataservice. For more information on methods for keeping the file in sync, see Section 7.6.7, “Synchronizing user.map Data”.

The user.map file contains the usernames and passwords for each user that connects to the connector and the downstream MySQL server, and these entries are required for authentication. If an entry does not exist within user.map users will be unable to connect to MySQL through the connector.


All the users that require access to your MySQL servers through the Tungsten Connector must have an entry in the user.map. Without this information, the Tungsten Connector has no way of providing an onward connection to a MySQL server.

The rules for the format of the file are as follows:

  • Anything after a # (hash) symbol are interpreted as comments and ignored. For example:

    # This line is a comment
  • The following character cannot be used as the username, password or dataservice values:

    |  # pipe
    \t # tab
  • Using the - (hyphen) character as a password indicates that there is an empty or no password ("") for the specified user.

The basic format for user entries within the user.map is:

username password servicename [affinity]


  • username — the username to be used for authentication.

    The username also provides hooks into additional options; see @script, @direct, @hostoption.

  • password — the password to be used for authentication.

    • Quotes ' and double quotes " are supported in the user.map password.

    • If there's a space in the password, the password needs to be surrounded with " or ':

      "password with space"
    • If there's one or several " or ' in the password without space, the password doesn't need to be surrounded

    • If the password itself starts and ends with the same quote (" or '), it needs to be surrounded by quotes.

      "'mypassword'" so that the actual password is 'mypassword'.

    As a general rule, if the password is enclosed in either single or double quotes, these are not included as part of the password during authentication.

  • servicename — the name of the dataservice or composite service to which this username/password apply.

  • affinity — if the servicename is a composite service, the affinity identifies which service should be preferred for reads.

    The affinity feature routes both reads and writes when using a Composite Active/Active topology.

    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.

    • 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.

For example, to configure the user sales with the password secret to use MySQL servers within the alpha dataservice:

sales secret alpha

To configure a user that has no password:

sales - alpha

To configure a user within a composite service:

sales secret global

To configure a user within a composite service, preferring the east service for read-only connections:

sales secret global east

Composite Specification in 6.0.3

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.

For example, to exclude site south from servicing read requests:

sales secret global 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 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