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
Binlog backup time of the DB instance	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 Parameters page of the data node console.

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 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 keys to the tables.
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.