Important
Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.
In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.
7. Checking Partition Number and Data Skew
On this page
This step checks whether there are enough partitions and if data is properly balanced across your cluster.
-
Check the total core-to-partition ratio per leaf for the database that is having trouble:
-
Run SHOW PARTITIONS on the database in question and compare that with the total number of cores in your cluster.
-
Is this ratio at least 1:1? If you have high concurrency, consider increasing the concurrency from 2, 3, or 4 to 1 core to partition ratio.
-
-
Check that your data is balanced across the cluster properly by running EXPLAIN REBALANCE PARTITIONS on the database in question.
If you see a non-empty set, run REBALANCE PARTITIONS on the database. -
Check that your data is redundant by running EXPLAIN RESTORE REDUNDANCY.
If you see a non-empty set, run RESTORE REDUNDANCY. -
Data Skew: refer to the Detecting and Resolving Data Skew.
Next Steps
-
If there are enough partitions and no data skew is detected: continue to Step 8.
Last modified: