PolarDB:Error codes

TDDL-4006 ERR_TABLE_NOT_EXIST

The error code is returned because the specified data table does not exist.

Example:

ERR-CODE: [TDDL-4006][ERR_TABLE_NOT_EXIST] Table '*****' doesn't exist.
            

This error code indicates that the data table does not exist in PolarDB-X 1.0 or PolarDB-X 1.0 has failed to load the metadata of the data table due to unknown reasons.

TDDL-4007 ERR_CANNOT_FETCH_TABLE_META

The error code is returned because PolarDB-X 1.0 has failed to load the metadata of a data table.

Example:

ERR-CODE: [TDDL-4007][ERR_CANNOT_FETCH_TABLE_META] Table '*****' metadata 
cannot be fetched because Table '*****.*****' doesn't exist.

This error code indicates that PolarDB-X 1.0 has failed to query the metadata of the data table. This error may occur due to one of the following reasons:

• The data table is not created.
• The data table in the database shard is manually deleted or renamed.
• PolarDB-X 1.0 cannot connect to the backend ApsaraDB RDS for MySQL instances.

If this error is returned, check whether the specified data table exists and confirm whether the status of all backend ApsaraDB RDS for MySQL instances of PolarDB-X 1.0 is normal.

If the data table is manually deleted or renamed, you can use the data restoration feature of ApsaraDB RDS for MySQL to restore the data.

TDDL-4100 ERR_ATOM_NOT_AVALILABLE

The error code is returned because a backend ApsaraDB RDS for MySQL instance of PolarDB-X 1.0 is unavailable.

Example:

ERR-CODE: [TDDL-4100][ERR_ATOM_NOT_AVALILABLE] Atom : ***** isNotAvailable

If PolarDB-X 1.0 detects that the status of an ApsaraDB RDS for MySQL instance on the backend is abnormal, PolarDB-X 1.0 temporarily blocks access to the instance and returns the TDDL-4100 error. If this error is returned, check whether the status of all backend ApsaraDB RDS for MySQL instances of PolarDB-X 1.0 is abnormal. If an abnormal ApsaraDB RDS for MySQL instance is detected, recover the related instance.

After the ApsaraDB RDS for MySQL instance is recovered, PolarDB-X 1.0 automatically changes the state of the instance and allows applications to access the instance.

TDDL-4101 ERR_ATOM_GET_CONNECTION_FAILED_UNKNOWN_REASON

The error code is returned because PolarDB-X 1.0 has failed to connect to a backend ApsaraDB RDS for MySQL instance due to unknown reasons.

Example:

ERR-CODE: [TDDL-4101][ERR_ATOM_GET_CONNECTION_FAILED_UNKNOWN_REASON] Get 
connection for db '*****' from pool failed. AppName:*****, Env:*****, 
UnitName:null. Message from pool: wait millis 5000, active 0, maxActive 5. 
You should look for the following logs which contains the real reason.

When PolarDB-X 1.0 processes requests, PolarDB-X 1.0 asynchronously establishes connections to the backend ApsaraDB RDS for MySQL instances. If PolarDB-X fails to connect to a backend ApsaraDB RDS for MySQL instance within a period of time and no error causes are returned for the asynchronous task, PolarDB-X 1.0 returns the TDDL-4101 error to the application.

In most cases, this error is returned because the status of the backend ApsaraDB RDS for MySQL instance is abnormal.

TDDL-4102 ERR_ATOM_GET_CONNECTION_FAILED_KNOWN_REASON

The error code is returned because PolarDB-X 1.0 has failed to connect to a backend ApsaraDB RDS for MySQL instance due to known reasons.

Example:

ERR-CODE: [TDDL-4102][ERR_ATOM_GET_CONNECTION_FAILED_KNOWN_REASON] Get 
connection for db '*****' failed because wait millis 5000, active 0, 
maxActive 5

This error code is returned if an error occurs when PolarDB-X 1.0 connects to a backend ApsaraDB RDS for MySQL instance. The error causes are included in the ERR-CODE message.

PolarDB-X 1.0 may fail to connect to a backend ApsaraDB RDS for MySQL instance due to one of the following reasons:

• The number of connections to the backend ApsaraDB RDS for MySQL instance has reached the upper limit.
• The connection to the backend ApsaraDB RDS for MySQL instance has timed out.
• The connection to the backend ApsaraDB RDS for MySQL instance is rejected.

TDDL-4103 ERR_ATOM_CONNECTION_POOL_FULL

The error code is returned because the connection pool of the backend ApsaraDB RDS for MySQL instances of PolarDB-X 1.0 is full.

Example:

ERR-CODE: [TDDL-4103][ERR_ATOM_CONNECTION_POOL_FULL] Pool of DB '*****' is 
full. Message from pool: wait millis 5000, active 5, maxActive 5. 
AppName:*****, Env:*****, UnitName:null.

This error code indicates that the backend connection pool of PolarDB-X 1.0 is full. The TDDL-4103 error may be returned due to one of the following reasons:

• The execution of SQL statements that are sent from an application is slow, and the operation is performed over a connection for a long period of time. As a result, the number of available connections is insufficient.
• An application does not close the connections to a database. This causes connection leaks.
• A large number of cross-database queries are performed in parallel. This operation is performed over a large number of connections. The cross-database queries include the queries for aggregation and statistical analysis and the queries for data in databases that are not sharded.

To resolve this error, we recommend that you use the following methods:

• Use frameworks such as Spring JDBC and MyBatis to connect to databases.
• Optimize SQL queries based on the performance analysis reports and suggestions of database administrators.
• Use the read/write splitting feature of PolarDB-X 1.0 to forward cross-database queries to read-only nodes.

• Upgrade the specifications of your ApsaraDB RDS for MySQL instances to improve the backend processing performance.

TDDL-4104 ERR_ATOM_CREATE_CONNECTION_TOO_SLOW

The error code is returned because the connection to a backend ApsaraDB RDS for MySQL instance of a PolarDB-X 1.0 instance has timed out.

Example:

ERR-CODE: [TDDL-4104][ERR_ATOM_CREATE_CONNECTION_TOO_SLOW] Get connection 
for db '*****' from pool timeout. AppName:*****, Env:*****, UnitName:null. 
Message from pool: wait millis 5000, active 3, maxActive 5.

When PolarDB-X 1.0 connects to a backend ApsaraDB RDS for MySQL instance in an asynchronously manner, the connection times out if a large number of connection requests are sent in a short period of time or it takes a long time to establish a connection to the backend ApsaraDB RDS for MySQL instance.

In most cases, this error occurs due to the heavy workloads on the backend ApsaraDB RDS for MySQL instance. To resolve this error, we recommend that you use the read/write splitting feature of PolarDB-X 1.0 or upgrade the specifications of the ApsaraDB RDS for MySQL instance.

TDDL-4105 ERR_ATOM_ACCESS_DENIED

The error code is returned because the connection request that PolarDB-X 1.0 sent to a backend ApsaraDB RDS for MySQL instance is rejected.

Example:

ERR-CODE: [TDDL-4105][ERR_ATOM_ACCESS_DENIED] DB '*****' Access denied for 
user '*****'@'*****'. AppName:*****, Env:*****, UnitName:null. Please 
contact DBA to check.

This error code indicates that the access request that includes a username and a password from PolarDB-X 1.0 to the ApsaraDB RDS for MySQL instance is rejected.

If the username or password that is automatically created by PolarDB-X 1.0 is changed on the backend ApsaraDB RDS for MySQL instance, PolarDB-X 1.0 returns the TDDL-4105 error for the access request.

PolarDB-X 1.0 also returns the TDDL-4105 error if the backend ApsaraDB RDS for MySQL instance expires or if an overdue payment occurs in your account. In this case, renew the instance at your earliest opportunity.

TDDL-4106 ERR_ATOM_DB_DOWN

The error code is returned because PolarDB-X 1.0 has failed to connect to a backend ApsaraDB RDS for MySQL instance.

Example:

ERR-CODE: [TDDL-4106][ERR_ATOM_DB_DOWN] DB '*****' cannot be connected. 
AppName:*****, Env:*****, UnitName:null. It seems a very real possibility 
that this DB IS DOWN. Please contact DBA to check.

This error code indicates that the connection request from PolarDB-X 1.0 to the backend ApsaraDB RDS for MySQL instance has timed out or no response is returned for the connection request. In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instance.

TDDL-4108 ERR_VARIABLE_CAN_NOT_SET_TO_NULL_FOR_NOW

The error code is returned because the value of a variable cannot be set to NULL.

Example:

ERR-CODE: [TDDL-4108][ERR_VARIABLE_CAN_NOT_SET_TO_NULL_FOR_NOW] System 
variable ***** can''t set to null for now;

You cannot execute the SET statement to set the value of some MySQL variables to NULL. If the value of such a variable is set to NULL, PolarDB-X 1.0 returns the TDDL-4108 error.

If this error occurs, check the value of the variable and rectify the value based on the official documentation of MySQL. For more information, see Server System Variables.

TDDL-4200 ERR_GROUP_NOT_AVALILABLE

The error code is returned because a PolarDB-X 1.0 database shard is unavailable.

Example:

ERR-CODE: [TDDL-4200][ERR_GROUP_NOT_AVALILABLE] The TDDL Group ***** is 
running in fail-fast status, caused by this SQL:***** which threw a fatal 
exception as *****.

If the backend ApsaraDB RDS for MySQL instance in which the database shard resides cannot be accessed and no other instances are available for the database shard, PolarDB-X 1.0 sets the status of the database shard to fail-fast and returns the TDDL-4200 error.

In most cases, this error occurs because the backend ApsaraDB RDS for MySQL instance fails. Troubleshoot the failure based on the error information. After the ApsaraDB RDS for MySQL instance is recovered, PolarDB-X 1.0 automatically changes the state of the instance from fail-fast.

TDDL-4201 ERR_GROUP_NO_ATOM_AVALILABLE

The error code is returned because no ApsaraDB RDS for MySQL instances are available for a PolarDB-X 1.0 database shard.

Example:

ERR-CODE: [TDDL-4201][ERR_GROUP_NO_ATOM_AVALILABLE] All weights of DBs in 
Group '*****' is 0. Weights is: *****.

When all ApsaraDB RDS for MySQL instances in which a database shard resides are unavailable or the database shard is in the fail-fast state, PolarDB-X 1.0 returns the TDDL-4201 error.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. Check the status of all backend ApsaraDB RDS for MySQL instances and resolve the fault.

TDDL-4202 ERR_SQL_QUERY_TIMEOUT

The error code is returned because a query in PolarDB-X 1.0 has timed out.

Example:

ERR-CODE: [TDDL-4202][ERR_SQL_QUERY_TIMEOUT] Slow query leads to a timeout 
exception, please contact DBA to check slow sql. SocketTimout:*** ms, 
Atom:*****, Group:*****, AppName:*****, Env:*****, UnitName:null.

This error code indicates that the execution duration of the SQL statement on the backend ApsaraDB RDS for MySQL instances exceeds the value of the socketTimeout parameter that you specified for your PolarDB-X 1.0 instance. The default value of the socketTimeout parameter is 900 seconds for your PolarDB-X 1.0 instance.

We recommend that you optimize the SQL statement and create suitable indexes on the backend ApsaraDB RDS for MySQL instances to improve the SQL query performance.

If the error persists after the SQL statement is optimized, use the following PolarDB-X 1.0 hint syntax to specify a temporary timeout period:

/*TDDL:SOCKET_TIMEOUT=900000*/ SELECT * FROM dual;

Specify the value of the SOCKET_TIMEOUT parameter in milliseconds.

For more information about PolarDB-X 1.0 hints, see Specify a custom time-out period for an SQL statement.

TDDL-4203 ERR_SQL_QUERY_MERGE_TIMEOUT

The error code is returned because a distributed query has timed out.

Example:

ERR-CODE: [TDDL-4203][ERR_SQL_QUERY_MERGE_TIMEOUT] Slow sql query leads to 
a timeout exception during merging results, please optimize the slow sql. 
The the default timeout is *** ms. DB is *****

When you query distributed data in PolarDB-X 1.0, the default timeout period is 900 seconds.

This error code indicates that the system has scanned the data in multiple database shards to execute the SQL statement and the execution duration is longer than 900 seconds. To optimize the SQL statement, perform the following steps:

• Include a shard key in the WHERE clause to specify a database shard on which you want to execute the SQL statement.
• Check whether a suitable index can be created on the backend ApsaraDB RDS for MySQL instances. Indexes can improve the query performance of a database shard.
• Eliminate time-consuming operations in the distributed query, such as cross-database JOIN queries and queries that are performed based on data resorting. This helps reduce the number of resources that are consumed during data merge operations.

If the error persists after the SQL statement is optimized, use the following hint syntax to specify a temporary timeout period for PolarDB-X 1.0:

/*TDDL:SOCKET_TIMEOUT=900000*/ SELECT * FROM dual;

Specify the value of the SOCKET_TIMEOUT parameter in milliseconds.

For more information about PolarDB-X 1.0 hints, see Specify a custom time-out period for an SQL statement.

TDDL-4400 ERR_SEQUENCE

The error code is returned because a sequence has failed to be processed.

Example:

ERR-CODE: [TDDL-4400][ERR_SEQUENCE] Sequence : All dataSource faild to get 
value!

This error code indicates that PolarDB-X 1.0 has failed to process the sequence. The error message is provided after Sequence :.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. As a result, data tables that are related to the sequence cannot be accessed. We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

TDDL-4401 ERR_MISS_SEQUENCE

The error code is returned because the specified sequence does not exist.

Example:

ERR-CODE: [TDDL-4401][ERR_MISS_SEQUENCE] Sequence '*****' is not found

This error code indicates that the sequence that you specified in the statement does not exist. We recommend that you execute the SHOW SEQUENCES statement to query the name of each sequence that you created in PolarDB-X 1.0 and specify a valid sequence name.

If the sequence that you want to use does not exist, you can use the following CREATE SEQUENCE syntax to create the sequence:

CREATE SEQUENCE <sequence name> [ START WITH <numeric value> ] 
[ INCREMENT BY <numeric value> ] [ MAXVALUE <numeric value> ] 
[ CYCLE | NOCYCLE ]` 

For more information about sequences, see Sequence.

TDDL-4403 ERR_MISS_SEQUENCE_TABLE_ON_DEFAULT_DB

The error code is returned because the data table that corresponds to a sequence does not exist.

Example:

ERR-CODE: [TDDL-4403][ERR_MISS_SEQUENCE_TABLE_ON_DEFAULT_DB] Sequence table 
is not in default db.

This error code indicates that the data table named sequence or sequence_opt cannot be found in the backend database.

TDDL-4404 ERR_SEQUENCE_TABLE_META

The error code is returned because the schema of the data table that corresponds to a sequence is invalid.

Example:

ERR-CODE: [TDDL-4404][ERR_SEQUENCE_TABLE_META] the meta of sequence table 
is error, some columns missed

This error code indicates that specific fields are missing in the data table that corresponds to the sequence. This data table can be the sequence or sequence_opt table.

TDDL-4405 ERR_INIT_SEQUENCE_FROM_DB

The error code is returned because a sequence has failed to be initialized.

Example:

ERR-CODE: [TDDL-4405][ERR_INIT_SEQUENCE_FROM_DB] init sequence manager 
error: *****

This error code indicates that the system has failed to initialize the sequence that you want to use. The error message is provided after init sequence manager error:.

We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

TDDL-4407 ERR_OTHER_WHEN_BUILD_SEQUENCE

The error code is returned because the data table that corresponds to a sequence cannot be accessed.

Example:

ERR-CODE: [TDDL-4407][ERR_OTHER_WHEN_BUILD_SEQUENCE] error when build 
sequence: *****

This error code is returned if an error occurs when you access a data table that corresponds to the sequence, such as the sequence or sequence_opt table. The error message is provided after error when build sequence:.

We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

DDL-4408 ERR_SEQUENCE_NEXT_VALUE

The error code is returned because the system has failed to obtain the values in a sequence.

Example:

ERR-CODE: [TDDL-4408][ERR_SEQUENCE_NEXT_VALUE] error when get sequence's 
next value, sequence is: *****, error: *****

This error code is returned if an error occurs when you obtain the values of a sequence by using a PolarDB-X 1.0 auto-increment primary key or the <sequence name>.NEXTVAL syntax. The cause of error is provided after error:.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. We recommend that you check the status of and access workloads on the backend ApsaraDB RDS for MySQL instances.

TDDL-4500 ERR_PARSER

The error code is returned because the SQL statement has failed to be parsed.

Example:

ERR-CODE: [TDDL-4500][ERR_PARSER] not support statement: '*****'

PolarDB-X 1.0 supports the SQL syntax that complies with the SQL-92 standard and the extended syntax and functions that are supported by MySQL. Check whether the SQL statement that you executed complies with the standard SQL syntax and MySQL specifications that are supported by PolarDB-X 1.0.

For more information about the standard SQL syntax, see Standard SQL syntax.

For more information about SQL statements that are compatible with PolarDB-X 1.0, see SQL limits.

TDDL-4501 ERR_OPTIMIZER

The error code is returned because the optimizer has failed to convert an SQL statement.

Example:

ERR-CODE: [TDDL-4501][ERR_OPTIMIZER] optimize error by: Unknown column 
'*****' in 'order clause'

The optimizer of PolarDB-X 1.0 can convert an SQL statement to an internal syntax tree. If a logic error occurs in an SQL statement, the optimizer fails to convert the SQL statement. In this case, the TDDL-4501 error is returned.

We recommend that you check and modify the SQL statement based on the cause of error. The cause of error is provided after optimize error by:.

TDDL-4502 ERR_OPTIMIZER_MISS_ORDER_FUNCTION_IN_SELECT

The error code is returned because the SELECT clause does not contain the columns that are returned by the function specified in the ORDER BY clause.

Example:

ERR-CODE: [TDDL-4502][ERR_OPTIMIZER_MISS_ORDER_FUNCTION_IN_SELECT] Syntax 
Error: orderBy/GroupBy Column ***** is not existed in select clause` 

In PolarDB-X 1.0, if the ORDER BY clause contains a function that returns columns, such as RAND(), the returned columns must also be specified in the SELECT clause. If the SELECT clause does not contain the returned columns, the TDDL-4502 error is returned.

We recommend that you include the corresponding columns in the SELECT clause.

TDDL-4504 ERR_OPTIMIZER_SELF_CROSS_JOIN

The error code is returned because an SQL statement does not meet the conditions that are required to perform a SELF JOIN query on a table.

Example:

ERR-CODE: [TDDL-4504][ERR_OPTIMIZER_SELF_CROSS_JOIN] self cross join case, 
add shard column filter on right table

When PolarDB-X 1.0 performs a SELF JOIN query on a table, the TDDL-4504 error is returned if the WHERE clause includes only the shard key of the left table or the right table.

We recommend that you include the shard keys of the left table and the right table in the WHERE clause in the SQL statement.

TDDL-4506 ERR_MODIFY_SHARD_COLUMN

The error code is returned because shard keys cannot be updated.

Example:

ERR-CODE: [TDDL-4506][ERR_MODIFY_SHARD_COLUMN] Column '*****' is a sharding 
key of table '*****', which is forbidden to be modified.

PolarDB-X 1.0 forbids you to change the value of a shard key by using the UPDATE statement. Update operations may change the shard where data resides. Therefore, PolarDB-X 1.0 cannot ensure data consistency and the atomicity of operations.

We recommend that you execute the DELETE and INSERT statements that have the same effect as the UPDATE statement to change the value of a shard key.

TDDL-4508 ERR_OPTIMIZER_NOT_ALLOWED_SORT_MERGE_JOIN

The error code is returned because the sort merge join operation cannot be performed.

Example:

ERR-CODE: [TDDL-4508][ERR_OPTIMIZER_NOT_ALLOWED_SORT_MERGE_JOIN] sort merge 
join is not allowed when missing equivalent filter

If the data tables on which you want to perform a join operation by executing an SQL statement are stored in different ApsaraDB RDS for MySQL instances, PolarDB-X 1.0 uses the sort-merge join algorithm. This algorithm can be used only if you specify the same join conditions for the left table and the right table in the SQL statement. If the join conditions that you specify for the left table are different from the join conditions that you specify for the right table, the TDDL-4508 error is returned.

We recommend that you include the equivalent JOIN conditions in the JOIN or WHERE clause in the SQL statement.

TDDL-4509 ERR_OPTIMIZER_ERROR_HINT

The error code is returned because the hint syntax is invalid.

Example:

ERR-CODE: [TDDL-4509][ERR_OPTIMIZER_ERROR_HINT] Hint Syntax Error: 
unexpected operation: *****.

This error code indicates that the syntax of the hint that you include in the SQL statement cannot be parsed by PolarDB-X 1.0. For more information about the hint syntax, see Overview.

TDDL-4510 ERR_CONTAINS_NO_SHARDING_KEY

The error code is returned because a shard key is not specified in an SQL statement.

Example:

ERR-CODE: [TDDL-4510][ERR_CONTAINS_NO_SHARDING_KEY] Your SQL contains NO 
SHARDING KEY '*****' for table '*****', which is not allowed in DEFAULT.

If the full table scan feature is not enabled for a PolarDB-X 1.0 table shard, you must include the shard key in the WHERE clause to access the table. If the WHERE clause does not contain the shard key, the TDDL-4510 error is returned.

When PolarDB-X 1.0 creates a table, the full table scan feature is enabled by default. If the full table scan feature is manually disabled, make sure that the shard key of the table is specified in each SQL statement that scans the data in the table.

TDDL-4511 ERR_INSERT_CONTAINS_NO_SHARDING_KEY

The error code is returned because a shard key is not specified in the INSERT statement.

Example:

ERR-CODE: [TDDL-4511][ERR_INSERT_CONTAINS_NO_SHARDING_KEY] Your INSERT SQL 
contains NO SHARDING KEY '*****' for table '*****'.

In PolarDB-X 1.0, if you want to execute the INSERT statement to insert the data of a sharded table, you must specify the shard key of the table in the INSERT statement unless the shard key is an auto-increment primary key. If the INSERT statement does not contain the shard key, the TDDL-4511 error is returned.

If this error occurs, we recommend that you include the shard key in the INSERT statement.

TDDL-4515 ERR_CONNECTION_CHARSET_NOT_MATCH

The error code is returned because the specified character set is not supported.

Example:

ERR-CODE: [TDDL-4515][ERR_CONNECTION_CHARSET_NOT_MATCH] Caused by MySQL's 
character_set_connection doesn't match your input charset. Partition DDL can 
only take ASCII or chinese column name. If you want use chinese table or 
column name, Make sure MySQL connection's charset support chinese character. 
Use "set names xxx" to set correct charset.

PolarDB-X 1.0 supports Chinese characters for table names and field names. The character_set_connection parameter specifies the character set that is used by a PolarDB-X 1.0 database to connect to a client. When you execute an SQL statement that contains Chinese characters, the TDDL-4515 error is returned if the character_set_connection parameter is set to a character set that does not support Chinese characters, such as latin1.

You can execute the SHOW VARIABLES LIKE 'character_set_connection' statement to query the character set that is used by a PolarDB-X 1.0 database to connect to a MySQL client. You can execute the SET NAMES statement to change the character set. If you use Java Database Connectivity (JDBC) to connect to a PolarDB-X 1.0 database, configure the characterEncoding parameter.

TDDL-4516 ERR_TRUNCATED_DOUBLE_VALUE_OVERFLOW

The error code is returned because an overflow has occurred when the system converts a floating-point number to an integer.

Example:

ERR-CODE: [TDDL-4516][ERR_TRUNCATED_DOUBLE_VALUE_OVERFLOW] Truncated 
incorrect DOUBLE value '*****' over column[*****]'s value range.

This error code indicates that the result is out of the valid range of integers when PolarDB-X 1.0 converts the floating-point number to an integer. We recommend that you check the data types of the specified columns and the input parameters in the SQL statement.

TDDL-4517 ERR_MODIFY_SYSTEM_TABLE

The error code is returned because system tables cannot be modified.

Example:

ERR-CODE: [TDDL-4517][ERR_MODIFY_SYSTEM_TABLE] Table '*****' is PolarDB-XSYSTEM 
TABLE, which is forbidden to be modified.

PolarDB-X 1.0 provides built-in system tables. If you execute an SQL statement to modify the data of a system table, the TDDL-4517 error is returned.

The following system tables cannot be modified: sequence, sequence_opt, txc_undo_log, and __DRDS__SYSTEM__LOCK__. Make sure that the names of system tables are not used when you create tables that store business data or when you design a database.

TDDL-4518 ERR_VALIDATE

The error code is returned because the metadata verification has failed.

Example:

ERR-CODE: [TDDL-4518][ERR_VALIDATE] Object 'optest1' not found

When a PolarDB-X 1.0 compute node receives an SQL statement, the compute node verifies the SQL statement based on existing metadata. This error code indicates that the table or column information that you want to query does not meet the requirements of metadata.

TDDL-4600 ERR_FUNCTION

The error code is returned because an error has occurred for a function call.

Example:

ERR-CODE: [TDDL-4600][ERR_FUNCTION] function compute error by Incorrect 
parameter count in the call to native function '*****'

This error code indicates that the SQL statement uses invalid syntax or contains invalid parameters to call the function. We recommend that you check whether the number and data type of parameters that you use to call the function in the SQL statement are valid.

TDDL-4601 ERR_EXECUTOR

The error code is returned because an error has occurred when the system executes the SQL statement.

Example:

ERR-CODE: [TDDL-4601][ERR_EXECUTOR] only one column is supported in 
distinct aggregate

This error code is returned if an unexpected error occurs when PolarDB-X 1.0 executes an SQL statement. In most cases, the error occurs because the status of a backend ApsaraDB RDS for MySQL instance is abnormal. We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

TDDL-4602 ERR_CONVERTOR

The error code is returned because the system has failed to convert a data type.

Example:

ERR-CODE: [TDDL-4602][ERR_CONVERTOR] convertor error by Unsupported convert: 
[*****]

This error code indicates that the data type cannot be converted when PolarDB-X 1.0 executes the SQL statement. Check whether the data that is used in the SQL statement requires implicit data type conversion. We recommend that you specify data of the same type for comparison and computing.

TDDL-4603 ERR_ACCROSS_DB_TRANSACTION

The error code is returned because a cross-database transaction has failed.

Example:

ERR-CODE: [TDDL-4603][ERR_ACCROSS_DB_TRANSACTION] Transaction accross db is 
not supported in current transaction policy, transaction node is: {0}, but 
this sql execute on: *****.

PolarDB-X 1.0 supports only single-database transactions. All SQL statements for single-database transactions must be forwarded to the same ApsaraDB RDS for MySQL database shard for execution based on the specified forwarding rules. Otherwise, the TDDL-4603 error is returned.

TDDL-4604 ERR_CONCURRENT_TRANSACTION

The error code is returned because a nested transaction has failed.

Example:

ERR-CODE: [TDDL-4604][ERR_CONCURRENT_TRANSACTION] Concurrent query is not 
supported on transaction group, transaction group is: {0}.

PolarDB-X 1.0 does not support nested transactions. If you attempt to start more than two transactions at the same time over the same database connection, the TDDL-4604 error is returned.

We recommend that you do not use nested transactions when you develop applications. You can abstract transactions into a transaction framework at the application layer. This way, no nested transactions are generated.

TDDL-4606 ERR_QUERY_C

The error code is returned because the execution of an SQL statement is canceled.

Example:

ERR-CODE: [TDDL-4606][ERR_QUERY_CANCLED] Getting connection is not allowed 
when query has been cancled, group is *****

When the KILL statement is executed to cancel the execution of an SQL statement, PolarDB-X 1.0 returns the TDDL-4606 error for the SQL statement. If this error frequently occurs, check whether the KILL statement is executed on a client or a program.

TDDL-4607 ERR_INSERT_WHEN_UPDATE

The error code is returned because an error has occurred when PolarDB-X 1.0 executes the UPDATE statement by executing the DELETE and INSERT statements.

Example:

ERR-CODE: [TDDL-4607][ERR_INSERT_WHEN_UPDATE] Insert new values error, 
table is: *****, old Values: *****, new Values: *****

After the shard key update feature is enabled, PolarDB-X 1.0 can replace the UPDATE statement that updates the shard key with the DELETE and INSERT statements. If the execution fails, the TDDL-4607 error is returned.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

TDDL-4610 ERR_CONNECTION_CLOSED

The error code is returned because a connection is closed.

Example:

ERR-CODE: [TDDL-4610][ERR_CONNECTION_CLOSED] connection has been closed

After an SQL statement in a transaction fails to be executed or the KILL statement is executed to cancel the execution of the SQL statement in the transaction, PolarDB-X 1.0 returns the TDDL-4610 error if you execute other SQL statements over the same database connection.

We recommend that you close the connection that executes the SQL statement and establish a new database connection.

TDDL-4636 ERR_DDL_JOB_ERROR

The DDL statement failed to be executed.

Example:

ERR-CODE: [PXC-4636][ERR_DDL_JOB_ERROR] xxxx

This error code indicates that the DDL statement failed to be executed. For information about how to resolve this error, see Handle DDL exceptions.

TDDL-4642 ERR_UNKNOWN_TABLE

The table does not exist in the database.

Example:

ERR-CODE: [PXC-4642][ERR_UNKNOWN_TABLE] Unknown table XX.XX

Check whether the table exists in the current database.

TDDL-1305 ERR_UNKNOWN_SAVEPOINT

The error code is returned because the specified savepoint does not exist.

Example:

ERR-CODE: [TDDL-1305][ERR_UNKNOWN_SAVEPOINT] SAVEPOINT ***** does not exist

When you execute the ROLLBACK TO SAVEPOINT or RELEASE SAVEPOINT statement in PolarDB-X 1.0, the TDDL-1305 error is returned if the specified savepoint does not exist.

We recommend that you check whether the savepoint that you specified in the SAVEPOINT statement is valid.

TDDL-1094 ERR_UNKNOWN_THREAD_ID

The error code is returned because the session ID that is specified in the KILL statement does not exist.

Example:

ERR-CODE: [TDDL-1094][ERR_UNKNOWN_THREAD_ID] Unknown thread id: *****

When you execute the KILL statement in PolarDB-X 1.0 to terminate an SQL statement that is being executed, the TDDL-1094 error is returned if the specified session ID does not exist or the SQL statement is already terminated.

We recommend that you execute the SHOW PROCESSLIST statement to query the session ID that corresponds to the SQL statement that you want to terminate and specify the queried session ID in the KILL statement.

TDDL-4612 ERR_CHECK_SQL_PRIV

The error code is returned because an SQL statement cannot be executed due to insufficient permissions.

Example:

ERR-CODE: [TDDL-4612][ERR_CHECK_SQL_PRIV] check user ***** on db ***** sql 
privileges failed.

PolarDB-X 1.0 provides a system that allows you to grant permissions to accounts. This system is similar to the account and permission system in MySQL. Only the accounts that are granted the required permissions can be used to execute the SQL statement. If the account that you use is not granted the required permissions, PolarDB-X 1.0 returns the TDDL-4612 error.

We recommend that you check the permissions that the account is granted on the PolarDB-X 1.0 database. If the account is not granted the required permissions, grant the permissions in the PolarDB-X 1.0 console.

TDDL-4613 ERR_INSERT_SELECT

The error code is returned because an error has occurred when PolarDB-X 1.0 executes the INSERT ... SELECT statement.

Example:

ERR-CODE: [TDDL-4613][ERR_INSERT_SELECT] insert error, table is: *****,
values: *****

PolarDB-X 1.0 allows you to split the INSERT ... SELECT statement that is executed across databases into the SELECT and INSERT statements and batch execute the statements. If the execution fails, the TDDL-4613 error is returned.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. We recommend that you check the status of all backend ApsaraDB RDS for MySQL instances.

TDDL-4614 ERR_EXECUTE_ON_MYSQL

The error code is returned because an error has occurred when PolarDB-X 1.0 executes the SQL statement on a backend ApsaraDB RDS for MySQL instance.

Example:

ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP '*****': Duplicate entry '*****' for key 'PRIMARY'

We recommend that you troubleshoot the error based on the error messages that are returned from the ApsaraDB RDS for MySQL instance. For more information about the error messages that are related to SQL statements, see MySQL 5.6 documentation.

TDDL-4615 ERR_CROSS_JOIN_SIZE_PROTECTION

The error code is returned because the number of rows that are returned for a distributed JOIN query exceeds the upper limit.

Example:

ERR-CODE: [TDDL-4615][ERR_CROSS_JOIN_SIZE_PROTECTION] across join table size protection, check your sql or enlarge the limination size .

When PolarDB-X 1.0 runs a distributed JOIN query in nested loops, a large number of memory resources are used if large amounts of data is returned from the right table. This affects the stability of PolarDB-X 1.0 in a negative manner. In PolarDB-X 1.0, the maximum number of rows that can be returned from a right table is 5,000. If this limit is exceeded, PolarDB-X 1.0 returns the TDDL-4615 error.

We recommend that you optimize the SQL statement to prevent large amounts of data from being returned from the right table, or use a better algorithm such as the sort-merge join algorithm to perform distributed JOIN operations in PolarDB-X 1.0.

TDDL-4616 ERR_UNKNOWN_DATABASE

The error code is returned because the specified database name is invalid.

Example:

ERR-CODE: [TDDL-4616][ERR_UNKNOWN_DATABASE] Unknown database '*****'

PolarDB-X 1.0 allows you to specify a database name in a DDL statement. If the database name that you specify is not the same as the database name provided by PolarDB-X 1.0, the TDDL-4616 error is returned.

We recommend that you change the database name in the DDL statement to ensure that the database name that you specify is the same as the database name provided by PolarDB-X 1.0.

TDDL-4617 ERR_SUBQUERY_LIMIT_PROTECTION

The error code is returned because the number of returned rows for a subquery exceeds the upper limit.

Example:

ERR-CODE: [TDDL-4617][ERR_SUBQUERY_LIMIT_PROTECTION] The number of rows returned by the subquery exceeds the maximum number of 20000.

When PolarDB-X 1.0 executes an SQL statement that contains a subquery, a large number of memory resources are used if large amounts of data is returned for the subquery. This affects the stability of PolarDB-X 1.0 in a negative manner. In PolarDB-X 1.0, the maximum number of rows that can be returned for a subquery is 20,000. If this limit is exceeded, PolarDB-X 1.0 returns the TDDL-4617 error.

We recommend that you optimize the subquery in the SQL statement to prevent large amounts of data from being returned. You can also rewrite the subquery into a JOIN query so that PolarDB-X 1.0 uses a more suitable algorithm such as the sort-merge join algorithm to perform JOIN operations.

TDDL-4800 ERR_SET_TXCID

The error code is returned because the system has failed to execute the SET TXC_ID statement.

Example:

ERR-CODE: [TDDL-4800][ERR_SET_TXCID] set txc_id failed: *****

TDDL-4801 ERR_TXCID_NULL

This error code is returned because NULL is returned when the SELECT LAST_TXC_ID statement is executed.

Example:

ERR-CODE: [TDDL-4801][ERR_TXCID_NULL] txc_xid is null: *****

TDDL-4802 ERR_SELECT_LAST_TXCID

The error code is returned because the system has failed to execute the SELECT LAST_TXC_ID statement.

Example:

ERR-CODE: [TDDL-4802][ERR_SELECT_LAST_TXCID] select last_txc_xid failed: *****

TDDL-4994 ERR_FLOW_CONTROL

The error code is returned because request throttling is triggered.

Example:

ERR-CODE: [TDDL-4994][ERR_FLOW_CONTROL] [*****] flow control by *****

This error code indicates that the number of SQL requests processed by PolarDB-X 1.0 has reached the upper limit and the current request is rejected.

We recommend that you check whether the peak value of the number of SQL requests is as expected.

TDDL-4998 ERR_NOT_SUPPORT

The error code is returned because the feature is not supported.

Example:

ERR-CODE: [TDDL-4998][ERR_NOT_SUPPORT] ***** not support yet!

This error code indicates that the SQL syntax or the feature that you use is not supported by PolarDB-X 1.0.

TDDL-5001 ERR_TRANS

The error code is returned because a common transaction error has occurred.

Example:

ERR-CODE: [TDDL-5001][ERR_TRANS] Too many lines updated in statement.

Resolve the error based on the error message. Too many lines updated in statement indicates that the number of rows that you want to update by executing the UPDATE statement exceeds the upper limit of 1,000. We recommend that you check the WHERE clause in the UPDATE statement. If you need to update a large amount of data in a transaction, you can use the /*TDDL:UNDO_LOG_LIMIT={number}*/ hint that is provided by PolarDB-X 1.0 to change the upper limit.

Deferred execution is only supported in Flexible or XA Transaction indicates that the deferred execution feature is available only for flexible or XA transactions. Before you use /*TDDL:DEFER*/ to enable deferred execution, execute the SET drds_transaction_policy = *** statement to change the transaction policy of your PolarDB-X 1.0 instance.

TDDL-5002 ERR_TRANS_UNSUPPORTED

The error code is returned because the syntax or the feature used in the transaction is not supported.

Example:

ERR-CODE: [TDDL-5002][ERR_TRANS_UNSUPPORTED] Table without primary keys is not
supported.

This error code indicates that this feature is not supported for PolarDB-X 1.0 transactions.

TDDL-5003 ERR_TRANS_LOG

The error code is returned because transaction logs cannot be accessed.

Example:

ERR-CODE: [TDDL-5003][ERR_TRANS_LOG] Failed to update transaction state: *****

When PolarDB-X 1.0 performs a distributed transaction, PolarDB-X 1.0 accesses the transaction logs in the backend ApsaraDB RDS for MySQL instances. This helps ensure the atomicity of the distributed transaction. If PolarDB-X 1.0 fails to read or write transaction logs, the TDDL-5003 error is returned.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. We recommend that you check the status of and access workloads on the backend ApsaraDB RDS for MySQL instances of your PolarDB-X 1.0 instance.

TDDL-5004 ERR_TRANS_NOT_FOUND

The error code is returned because the specified transaction ID does not exist.

ERR-CODE: [TDDL-5008][ERR_TRANS_TERMINATED] Current transaction was killed 
or timeout. You may need to set a longer timeout value.          

This error code indicates that the specified transaction is terminated by the KILL statement or the execution has timed out. The timeout period of a transaction is specified by the drds_transaction_timeout parameter.

If this error is returned due to a transaction timeout, we recommend that you execute the SET drds_transaction_timeout = *** statement to change the timeout period for the transaction. Specify the value of the drds_transaction_timeout parameter in milliseconds.

TDDL-5006 ERR_TRANS_COMMIT

The error code is returned because PolarDB-X 1.0 has failed to commit a transaction.

ERR-CODE: [TDDL-5006][ERR_TRANS_COMMIT] Failed to commit primary group *****: 
*****, TRANS_ID = ***** 

If an error occurs when PolarDB-X 1.0 commits a transaction, the transaction is automatically rolled back. TRANS_ID indicates the ID of the transaction.

In most cases, this error occurs because a fault occurs in the backend ApsaraDB RDS for MySQL instances. We recommend that you check the status of and access workloads on the backend ApsaraDB RDS for MySQL instances of your PolarDB-X 1.0 instance.

TDDL-5007 ERR_TRANS_PARAM

The error code is returned because the specified transaction parameter is invalid.

ERR-CODE: [TDDL-5007][ERR_TRANS_PARAM] Illegal timeout value: ***** 

This error code indicates that you specified an invalid value for the transaction parameter in the statement. For example, in the SET drds_transaction_timeout = *** statement, the drds_transaction_timeout parameter is set to a negative number.

TDDL-5008 ERR_TRANS_TERMINATED

The error code is returned because a transaction is terminated by the KILL statement or due to a timeout.

ERR-CODE: [TDDL-5008][ERR_TRANS_TERMINATED] Current transaction was killed 
or timeout. You may need to set a longer timeout value.             

This error code indicates that the specified transaction is terminated by the KILL statement or the execution has timed out. The timeout period of a transaction is specified by the drds_transaction_timeout parameter.

If this error is returned due to a transaction timeout, we recommend that you execute the SET drds_transaction_timeout = *** statement to change the timeout period for the transaction. Specify the value of the drds_transaction_timeout parameter in milliseconds.