[MXS-4079] Document cooperative monitoring conflict probability Created: 2022-04-06  Updated: 2022-05-10  Resolved: 2022-05-10

Status: Closed
Project: MariaDB MaxScale
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.5.20

Type: Task Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Attachments: PDF File Cooperative Monitoring Conflict Probabilities.pdf    
Issue Links:
Relates
relates to MXS-3234 Resolve cooperative monitoring deadlocks Closed
Sprint: MXS-SPRINT-156

 Description   

The documentation currently is not clear enough about how the feature works and why complex conflict resolution strategies are not needed. Explaning that the probability of a conflict is small due to the randomness involved in the lock acquisition goes a long way to help the users understand why MaxScale behaves the way it does.

 Comments   
Comment by markus makela [ 2022-05-05 ]

Added the numbers for a simplified model on conflict probabilities with cooperative monitoring.

The following is used as the model for the conflict probability for getting the server locks:
randomly distribute n balls in m boxes and calculate the probability of no box having over half of all balls in them

The following is used as the model for conflicting retry probabilities after a lock acquisition fails and no MaxScale gets a majority of the servers:
roll a 4-sided dice m times and calculate the probability of having only doubles, triples, quads etc. with no value being rolled only once

Values were calculated experimentally using a script that generates all states and then counts the number of conflicting ones.

Generated at Thu Feb 08 04:26:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.