Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
MXS-SPRINT-131
Description
The current causal_reads mechanism relies on the SQL in question being modifiable. As this is not possible for COM_STMT_EXECUTE queries, a different synchronization mechanism must be created for causal_reads=local and causal_reads=global.
One option is to route a normal COM_QUERY packet with the MASTER_GTID_WAIT to the server and then sending the COM_STMT_EXECUTE without waiting for the response. The result of the MASTER_GTID_WAIT would be ignored and the query would never be retried if the MASTER_GTID_WAIT failed. This mode would have a "best-effort" guarantee of the causality of the reads.
Another option is to just wait for the COM_QUERY to finish before sending the COM_STMT_EXECUTE to the server. This would still improve read scaling but it would roughly double the latency for each query.
The third option is to use the BEGIN NOT ATOMIC syntax combined with immediate execution of prepared statements. This retains the same limitations and benefits that the COM_QUERY ONE does with the exception of causing an extra prepare-execute-close cycle to occur in the server.
Original description:
Hi
Maxscale is not able to deal with causal read and read/write split. This force to use only one node of the topology in place.
Attachments
Issue Links
- duplicates
-
MXS-3315 Add prepared statement support to causal_reads
- Closed