[MCOL-788] redistributeData does nothing for partitions that are evenly spread across dbroots Created: 2017-06-26  Updated: 2023-10-25  Resolved: 2023-10-25

Status: Closed
Project: MariaDB ColumnStore
Component/s: writeengine
Affects Version/s: 1.0.9
Fix Version/s: Icebox

Type: Bug Priority: Major
Reporter: David Thompson (Inactive) Assignee: Leonid Fedorov
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Relates
relates to MCOL-455 redistribute data's "START REMOVE" op... Closed
relates to MCOL-786 redistribute remove moved data from r... Closed

 Description   

If you have data loaded near perfectly with one dbroot overloaded but the partitions are distributed across all dbroots, then redistributeData will do nothing. In this case the cluster got into this state due to bug MCOL-786, but it should be possible to also reproduce this other ways such as using mode 1 to load a bunch of rows perfectly and then use mode 3 or limit the load to 1 pm such that that pm has a bunch more data.

This configuration will not do any redistribute, but it should try to reduce the size of the overloaded dbroot and spread this out across the remaining dbroots.



 Comments   
Comment by David Thompson (Inactive) [ 2017-06-26 ]

This is a case that was mentioned in MCOL-455 but not included in the scope of that fix which was for remove.

Comment by David Thompson (Inactive) [ 2017-06-26 ]

MCOL-786 is a bug that caused an instance to get into this state where removing dbroot2 resulted in all the records going to dbroot1. The hope was that a subsequent redistribute would rebalance but it did nothing.

Comment by David Thompson (Inactive) [ 2017-06-26 ]

I believe the logic at L340 of RedistributeControlThread::makeRedistributePlan is the flaw here, it tries to avoid moving a partition to a dbroot if that dbroot already contains the partition but there is no fallback case if all are full.

Comment by David Thompson (Inactive) [ 2017-06-26 ]

see MCOL-786 for scripts to reproduce.

Generated at Thu Feb 08 02:23:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.