[MXS-3663] Causal Reads Global Cluster Distribution Created: 2021-07-08 Updated: 2022-04-13 Resolved: 2022-01-28 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | readwritesplit |
| Affects Version/s: | None |
| Fix Version/s: | 22.08.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Todd Stoffel (Inactive) | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 2 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Sprint: | MXS-SPRINT-146, MXS-SPRINT-147, MXS-SPRINT-148, MXS-SPRINT-149 | ||||||||||||
| Description |
|
Causal reads currently only works in a single MaxScale instance environment however for the purposes of HA, many customers are running multiple MaxScale servers. If the application is going though a load balancer like F5 or NLB, those connections are round robin'd to the various MaxScale instance and the benefit of causal reads is lost. We should devise a strategy to sync that information among MaxScale nodes. |
| Comments |
| Comment by markus makela [ 2021-12-08 ] |
|
One way to implement this would be to execute a SELECT @@gtid_binlog_pos before each read to make sure the connection uses the latest binlogged GTID for the upcoming read. This would roughly double the maxscale-to-db latency for each causal read done in this manner but it should improve throughput slightly: doing this no longer requires a global lock in readwritesplit as each session does the read separately. |
| Comment by markus makela [ 2022-01-28 ] |
|
The solution that we ended up selecting was to send a SELECT @@gtid_current_pos query to the primary node of the cluster before each read. This guarantees that when a read query arrives on MaxScale, it will see at least the latest observable GTID position in the cluster. Same as with the other causal read modes, this it means that if a client executes statement A before statement B, B will always see any effects that A has on the cluster, that is A happens-before B. |