[MXS-497] MaxScale does not contemplate client multiple statements (CLIENT_MULTI_STATEMENTS) Created: 2015-12-02 Updated: 2016-03-01 Resolved: 2016-03-01 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | 1.2.0, 1.2.1 |
| Fix Version/s: | 1.4.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | Claudio Nanni | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | CLIENT_MULTI_RESULTS, CLIENT_MULTI_STATEMENTS | ||
| Description |
|
Tested with Visual Studio, .NET connector, C#, MaxScale 1.21, MariaDB Galera 10.0 When enabling CLIENT_MULTI_STATEMENTS (AllowBatch=true in .NET connector) MaxScale can't manage properly multiple statements execution and status control since it considers it just like one single statement. Two main issues: 1) The whole semicolons separated commands string is forwarded to one single server, in case of R/W split module that means that a command starting with SELECT... but having INSERT and updates will go to a R(ead) node. for example (apparently the decision on the type of command(R/W) is done on the first match). 2) The status returned from the command is not properly parsed, so that some commands may fail without MaxScale detecting it, indeed with CLIENT_MULTI_STATEMENTS (and CLIENT_MULTI_RESULTS) the parsing should loop on the array of the executed commands, not just read one of them. Claudio |
| Comments |
| Comment by Johan Wikman [ 2015-12-03 ] |
|
Seems like a real problem. A fix tentatively targeted to 1.3.1. |
| Comment by markus makela [ 2016-02-29 ] |
|
Currently the only safe way to process multi-statement queries without parsing them is to route them and all future queries to the master. This will guarantee that no data modification happens on slaves and that the session state stays coherent. In the future this could behave in a smarter way and parse the individual queries. This would allow multi-statement selects to be routed to slaves and bulk inserts to the master while still allowing reads to slaves. Ideally, the behavior would be configurable. |