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	Log in to the data node console and ensure that the full backup retention period is more than 30 days.
Binlog enabled on data nodes	Whether binlog is enabled to support online shard configuration	If your data node is an RDS instance, ensure that Binlog is enabled.
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.
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.