wirybeaver commented on PR #15203:
URL: https://github.com/apache/pinot/pull/15203#issuecomment-2970465878

   > > useFixedReplica is not a good idea
   > 
   > I'm not sure how `useFixedReplica` came into the picture here, it's 
totally unrelated. What I meant was that if you want to actually use "preferred 
replica groups" and not preferred instance pools, you could take a look at 
[MultiStageReplicaGroupSelector](https://github.com/apache/pinot/blob/6e8e3d2984d8853b85f48552bda4fe3348cf91aa/pinot-broker/src/main/java/org/apache/pinot/broker/routing/instanceselector/MultiStageReplicaGroupSelector.java#L57)
 to see how it's fetching the replica group ID for an instance from the table's 
`INSTANCE_PARTITIONS` in ZK.
   > 
   > > Let say a replica group is distributed among multiple pools
   > 
   > A replica group for a table in Pinot can't be distributed among multiple 
pools, it can only belong to a single instance pool. The other way around is 
possible though - an instance pool can have more than one replica group 
assigned to it (even for a single table).
   
   Yeah, I already realized the fact that a replica won't distributed among 
multiple pools **in theory** when I did changes on the 
StrictReplicaGroupSelector and read the comment "The algorithm relies on the 
mirror segment assignment from replica-group segment assignment strategy. With 
mirror segment assignment, any server in one replica-group will always have a 
corresponding server in other replica-groups that have the same segments 
assigned." The concern would be the edge case that segment relocation, for 
example, table rebalance.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to