Updated on 2024-04-01 GMT+08:00

Pre-check

Check items in the table below one day before performing a shard configuration task.

Pre-check Items

Table 1 Pre-check items involved

Item

Purpose

Solution to Check Failure

Table name length

Redistributing data (for example, adding shards) will generate a temporary table whose name is longer than the original table. Ensure that the name of a temporary table does not exceed the maximum length defined by MySQL.

Modify the table name that is too long.

Binlog full backup time of the data node

Whether your full backups are retained for a time period long enough

Increase the retention period for full backups on the data node console.

Binlog enabled on data nodes

Whether binlog is enabled to support online shard configuration

If your data node is an RDS instance, no further action is required. If your data node is a GaussDB(for MySQL) instance, set log_bin to true on the GaussDB(for MySQL) console.

Retention period of binlogs on data nodes

The retention period of binlogs on data nodes must be long enough.

If your data node is an RDS instance, no further action is required. If your data node is a GaussDB(for MySQL) instance, set binlog_expire_logs_seconds to 604800 or a larger value.

Broadcast table consistency

Ensure broadcast table consistency before performing a shard configuration task.

Contact DDM O&M personnel.

Character set and collation of source shards

Ensure that character set and collation are consistent before and after the shard configuration.

Contact DDM O&M personnel.

SQL statements for creating physical stables.

Ensure that table structure on physical shards is consistent.

Execute CHECK TABLE to check for table structure inconsistencies and execute ALTER to rectify the inconsistencies.

Primary keys

All tables in the source database have primary keys, and the sharding key is a part of the primary keys to ensure data consistency after shards are changed.

Add primary keys for tables using ALTER if the tables have no primary keys.

Access to DB instances

Check whether data nodes can be connected.

Check security group configurations.

DB instance parameters

The source data nodes have the same DB parameter settings as the destination data nodes.

Modify parameter configurations on the data node console.

DB instance storage space

The disk space of data nodes is sufficient during shard configuration.

Scale up storage space of data nodes.

CAUTION:

This check item is based on the estimated value that may be different from the actual value.

DB instance time zone

The source data nodes have the same time zone requirements as the destination data nodes.

Modify the time zone on the data node console.

Maximum number of physical tables

When you add shards, each data record in the source table will be rerouted to a new physical table. It takes a long time for sharding if there are too many physical tables. Check whether the number of physical tables on each node exceeds the upper limit.

Contact customer service.

Common Issues and Solutions

  • The shard configuration fails due to table structure inconsistency.

    Solution: Execute CHECK TABLE to query table structure inconsistencies and execute ALTER TABLE to rectify the inconsistencies. Contact O&M personnel if the inconsistencies cannot be rectified using DDL, for example, the primary or unique keys cannot be modified for data reasons.

  • Tables without primary keys cannot be migrated. If a table has no primary keys, it cannot be correctly located and recorded. After a retry is performed during shard configuration, duplicate data may be generated.

    Solution: Add a primary key to the table.

  • If the sharding key is not part of a primary key, there may be data records (in different physical tables) with duplicate primary key values in a logical table. When these data records are redistributed, they will be routed to the same physical table, and only one record is retained because they have the same primary keys. As a result, data becomes inconsistent before and after the migration, causing the shard configuration failure.

    This error does not occur when the primary key is a globally unique sequence and the number of shards does not change.

    Solution: Rectify the data and check again.