Pre-check¶
Check items in the table below one day before performing a shard configuration task.
Pre-check Items¶
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 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.
Note
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.