This feature will allow the connector behavior to be changed based on the
connection count. The connector is able to mimic MySQL's
max_connections. Depending on your needs, the connector
can be configured to pile up or reject connections above this number. This
is served by the following two tpm flags:
--connector-max-connections - defines the
maximum number of connections the connector should allow at any time.
When the connector-max-connections is set
to a non-zero numeric value, the connector denies access to the client in
one of two ways: queue (default) or reject.
--connector-drop-after-max-connections -
defines how the connector should handle new connection requests - queue
(default) or reject.
Enabling this option causes the connector to drop new connection requests
when connector-max-connections is reached
by immediately sending a "Too Many Connections" error to the client, just
like MySQL would.
When a client connection request arrives at the connector, an object is created to track that client connection which uses a certain amount of memory.
The connector then checks the value of
connector-max-connections against the
current connection count.
If the connection limit has been reached, the connector decides how to
behave by checking the value of
connector-drop-after-max-connections.
If connector-drop-after-max-connections
is false (the default), the connector will queue the connection request,
but send nothing back to the client at all. This connection check will
repeat after a delay. Once the connection count falls below
connector-max-connections an attempt to
connect to a server is made. In this mode, connections will continue to
pile up in memory as new requests are queued, resulting in an Out of
Memory error. For this reason, the
connector-drop-after-max-connections is
available to prevent connection queueing when the maximum number of
connections has been reached.
If connector-drop-after-max-connections
is enabled, the connector will return a "Too Many Connections" error to
the client and remove the client connection object, freeing memory.
To enable connector-max-connections:
Click the link below to switch examples between Staging and INI methods...
shell>tpm query stagingtungsten@db1:/opt/continuent/software/tungsten-clustering-6.1.25-6 shell>echo The staging USER is `tpm query staging| cut -d: -f1 | cut -d@ -f1`The staging USER is tungsten shell>echo The staging HOST is `tpm query staging| cut -d: -f1 | cut -d@ -f2`The staging HOST is db1 shell>echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-6.1.25-6 shell>ssh {STAGING_USER}@{STAGING_HOST}shell>cd {STAGING_DIRECTORY}
shell> ./tools/tpm configure alpha \
--connector-max-connections=2500
Run the tpm command to update the software with the Staging-based configuration:
shell> ./tools/tpm updateFor information about making updates when using a Staging-method deployment, please see Section 10.3.7, “Configuration Changes from a Staging Directory”.
shell> vi /etc/tungsten/tungsten.ini[alpha]
...
connector-max-connections=2500
Run the tpm command to update the software with the INI-based configuration:
shell>tpm query stagingtungsten@db1:/opt/continuent/software/tungsten-clustering-6.1.25-6 shell>echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-6.1.25-6 shell>cd {STAGING_DIRECTORY}shell>./tools/tpm update
For information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
To enable
connector-drop-after-max-connections you
must also set a non-zero value for
connector-max-connections:
shell> ./tools/tpm configure alpha \
--connector-drop-after-max-connections=true \
--connector-max-connections=2500
[alpha]
connector-drop-after-max-connections=true
connector-max-connections=2500
Configuration group alpha
The description of each of the options is shown below; click the icon to hide this detail:
--connector-drop-after-max-connections=true
connector-drop-after-max-connections=true
Instantly drop connections that arrive after --connector-max-connections has been reached
--connector-max-connections=2500
connector-max-connections=2500
The maximum number of connections the connector should allow at any time
Updating these values require a connector restart (via tpm update) for the changes to be recognized.
To select a real-world value for
connector-max-connections, set the value to
a value slightly lower than the MySQL value of
max_connections to prevent the server from ever hitting
maximum. You may use the following formula for a more complex calculation:
connector-max-connections = ( MySQL Primary
max_connections / number of connectors ) * 0.95
When connector-drop-after-max-connections
is enabled, be sure that your load balancers are configured to identify
that max connections have been reached and to switch to another connector
when that happens.