Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
None
-
SkySQL Dev/Test
Description
Original title: SkySQL:Data inconcistencies observed in replicas after upgrade to maxscale:2.4.2
After upgrade from maxscale:2.3.9 to maxscale to maxscale:2.4.2 in SkySQL, we started observing replicas data inconsistencies in the scenario of topology initialization followed by immediate data load.
Detail of these issues can be found here:
https://jira.mariadb.org/browse/DBAAS-1319
https://jira.mariadb.org/browse/DBAAS-1318
We did a bit of a research on our end investigating possible root cause in various moving parts - test clusters/topologies setup , operator/K8s, etc.
were not able to find anything obvious, apart from the maxscale migration from 2.3.9 to 2.4.2
So far we tried a couple of suggestion from the MaxScale team :
- Consistent Critical Read Filter
- Using Causal reads
unfortunately without much of a success.
Please advice, if you need further detail on the issue or any other form of support we can provide you with to speed up the resolution process
Attachments
Activity
users_refresh_time=0 seems to work, thank you.
I'll check if it's a safe setting to have and remove my hacky workaround.
So the only thing left to say here is that whether it's a bug or not, the behavior is different from 2.3.9, where we had no such problem.
From the documentation:
In MaxScale 2.3.9 and older versions, the minimum allowed value was 10 seconds but, due to a bug, the default value was 0 which allowed infinite refreshes.
This is still probably a bug in MaxScale and how it limits the user loading at startup.
There's already code in place that prevents the user loading rate limitation from triggerting shortly after startup which means this is most likely expected behavior and the rate limitation should be disabled.
I think there might be a problem where the user loading rate limit is triggered too early. If you add users_refresh_time=0 under the [maxscale] section, does it work?