Help Center/ Distributed Database Middleware/ User Guide/ Instance Management/ Modifying Parameters of a DDM Instance
Updated on 2022-09-16 GMT+08:00

Modifying Parameters of a DDM Instance

Scenarios

Configure parameters of a DDM instance based on your needs to keep the instance running well.

Prerequisites

There is a DDM instance available and running normally.

Procedure

  1. Log in to the DDM console.
  2. In the navigation pane, choose Instances.
  3. In the instance list, locate the DDM instance whose parameters you want to configure and click its name.
  4. In the left pane, click Parameters and modify parameter values as needed.

    Table 1 Parameters of a DDM instance

    Parameter

    Default Value

    Value Range

    Description

    bind_table

    -

    The value should be in format [{tb.col1,tb2.col2},{tb.col2,tb3.col1},...]. tb.col1,tb2.col2 indicates a table name.column name pair, and the value may contain multiple pairs.

    The version should be:

    DDM 2.3.2.7 or later.

    Data association among multiple sharded tables. The optimizer processes JOIN operations at the MySQL layer based on these associations. For details about parameter examples, see the description below the table.

    character_set_server

    utf8mb4

    gbk, utf8, utf8mb4

    DDM server's character set. To store emoticons, set both this parameter and the character set on RDS to utf8mb4.

    For a DDM instance 3.0.9 or later, you can execute show variables like '%char%' to query its character set. You will find that character_set_client, character_set_results, and character_set_connection in the command output all have a fixed value, utf8mb4.

    collation_server

    utf8mb4_unicode_ci

    utf8mb4_unicode_ci, utf8mb4_bin, utf8mb4_general_ci

    Collation on the DDM server.

    concurrent_execution_level

    DATA_NODE

    RDS_INSTANCE, DATA_NODE, PHY_TABLE

    Concurrency level of scanning table shards in a logical table. DATA_NODE: indicates that database shards are scanned in parallel and table shards in each database shard are scanned in serial. RDS_INSTANCE: indicates that RDS instances are scanned in parallel and shards in each DB instance are scanned in serial. PHY_TABLE: indicates that all table shards are scanned in parallel.

    connection_idle_timeout

    28800

    60—86400

    Number of seconds the server waits for activity on a connection before closing it. The default value is 28800, indicating that the server waits for 28800 seconds before closing a connection.

    contains_shard_key

    OFF

    OFF or ON

    Whether the SELECT, UPDATE, and DELETE statements must contain sharding keys in filter conditions.

    ddl_precheck_mdl_threshold_time

    120

    0–3600

    Threshold of the MDL duration in DDL pre-check. The unit is second. The default value is 120.

    enable_table_recycle

    OFF

    OFF or ON

    ON: indicates that the table recycle bin is enabled.

    OFF: indicates that the table recycle bin is disabled.

    After the table recycle bin is enabled, deleted tables are moved to the recycle bin and can be recovered by running the RESTORE command within seven days.

    long_query_time

    1

    0.01–10

    Minimum duration of a query to be logged as slow, in seconds. The default value is 1, indicating that the query is considered as a slow query if its execution duration is greater than or equal to 1 second.

    max_allowed_packet

    1073741824

    1024–1073741824

    Maximum size of one packet or any generated intermediate string. The packet message buffer is initialized to net_buffer_length bytes, but can grow up to max_allowed_packet bytes when needed. This value is small by default, to catch large (and possibly incorrect) packets. The value must be a multiple of 1024.

    max_backend_connections

    0

    0—10000000

    Maximum of concurrent client connections allowed per DDM instance. When this parameter is set to 0 (default), the maximum concurrent connections from a DDM node to an RDS instance is: (RDS instance's maximum connections - 20)/DDM nodes.

    max_connections

    20000

    10–40000

    Maximum number of concurrent client connections allowed per DDM instance.

    This value depends on specifications and processing capabilities of the target data node. Too many connections may cause connection waiting, affecting performance. The consumption of DDM connections varies with the number of shards and SQL design.

    For example, If a SQL statement contains a sharding key, each DDM connection consumes one data node connection. If the SQL statement contains no sharding keys and the number of shards is N, N data node connections are consumed.

    If SQL design is appropriate and processing capabilities of DDM and its data nodes are good enough, you can set this parameter to a value slightly smaller than the product of backend data nodes x maximum connections supported by each data node.

    Carry out pressure tests on your services and then select a proper value.

    min_backend_connections

    10

    0—10000000

    Minimum concurrent connections from a DDM node to an RDS instance. The default value is 10.

    seconds_behind_master

    30

    0—7200

    Threshold in seconds of the replication lag between a primary RDS instance to its read replica. The default value is 30, indicating that the time for data replication between the primary RDS instance and its read replicas cannot exceed 30 seconds. If the time exceeds 30 seconds, the data read requests are no longer forwarded to the read replicas.

    sql_execute_timeout

    28800

    100—28800

    Number of seconds to wait for a SQL statement to execute before it times out. The default value is 28800, indicating that the SQL statement times out if its execution time is greater than or equal to 28800 seconds.

    temp_table_size_limit

    1000000

    500000–2000000000

    Size of a temporary table.

    transaction_policy

    XA

    XA, FREE, NO_DTX

    Transactions supported by DDM. XA transaction, which attempts to ensure atomicity and isolation. FREE transaction, which is a best-effort commit transaction that allows data to be written to multiple shards, without impacting performance. FREE transactions do not ensure atomicity. NO_DTX transaction, which is a single-shard transaction.

    transfer_hash_to_mod_hash

    OFF

    OFF or ON

    Whether the hash algorithm must be converted into mod_hash during table creation.

    ultimate_optimize

    ON

    OFF or ON

    Whether the SQL execution plan is optimized based on parameter values.

    force_read_master_in_transaction

    OFF

    OFF or ON

    Whether SQL statements involved in each transaction are read from the master node.

    CAUTION:

    This parameter is available in version 3.0.9 or later. If this feature is enabled in version 3.0.9 but the version is downgraded to 3.0.9 below, the feature keeps enabled when the version returns to 3.0.9 or later.

    By default, DDM allows you to modify only the preceding instance parameters. If you need to modify other parameters in some special scenarios such as data migration, contact technical support.

    Parameter configuration examples:
    Figure 1 Result if bind_table is not used
    Figure 2 Result if bind_table is used

  5. Click Save in the upper left corner and then Yes in the displayed dialog box.

    • Modifying parameters may affect access to the DDM instance. Exercise caution when performing this operation.
    • It takes 20s to 60s to have the modifications to take effect.