repair: add control for repair percentage for partition count estimation about scylladb HOT 2 CLOSED

642f9a1 slashes partition count estimates during repair by 10%, based on the assumption that in average, around 10% of the data is moved by repair. This number is pulled from thin air, and while I expect in most cases it will be fine, in certain cases it will be a gross under-estimation and can lead to bloom filters violating FP chance and generating more IO.

What's the interaction between estimation and RBNO, which moves all of the data?

After e.g. bootstrap, are the repair-written sstables used as they are (and in this case — won't 642f9a1 make their filters very ineffective?), or are they guaranteed to go through some kind of compaction (reshape?) first, which will fix their filters?

from scylladb.

642f9a1 slashes partition count estimates during repair by 10%, based on the assumption that in average, around 10% of the data is moved by repair. This number is pulled from thin air, and while I expect in most cases it will be fine, in certain cases it will be a gross under-estimation and can lead to bloom filters violating FP chance and generating more IO.

What's the interaction between estimation and RBNO, which moves all of the data?

Most of the RBNO operations will move all of the data for a given range. Node ops like rebuild might move only few data in case the node already has some of the data.

After e.g. bootstrap, are the repair-written sstables used as they are (and in this case — won't 642f9a1 make their filters very ineffective?), or are they guaranteed to go through some kind of compaction (reshape?) first, which will fix their filters?

The sstables generated by RBNO will go through off strategy compaction which will integrate them to main dataset. This will fix the filters.

Also the new node is supposed to have a lower "heat" so that the heat_load_balance will route less traffic to it.

from scylladb.