So everything should go to master?
Why is readconnroute with router_options=master not applicable?

We should skip query parser overhead as well with this.

toddstoffel Would setting this to "none" bypass the query parsing (thus reduce/eliminate the overhead of read/write split)?

Another way to tackle this would be a much bigger, longer-term project to maybe merge the routers.

Fundamentally they are quite different, RCR being connection oriented and RWS being statement oriented. Once the connection has been established, RCR is in its simplest form basically a switch; it just forwards bytes from one port to another, without any knowledge about the data that is being transferred. However, if a filter that needs to be aware of statements is added to the routing chain that's no longer quite true. The names of both routers are currently rather far from what they actually are; readconnroute suggests that it could only be used for reading, which is not the case, and readwritesplit suggests that it would always do read write splitting, which is not the case if the backend is xpand, although it makes perfect sense to use it nonetheless. If they were renamed as connection oriented router and statement oriented router, the situation would be clearer. Starting from scratch things could be arranged quite differently of course. There could be just a single router, and then for starters you would have to configure whether the backend is chosen at connection creation time or at each statement/transaction boundary. That choice would then affect what other choices you can make.

A simpler approach is to just use max_slave_connections=0 and fix the bug that it currently has where it requires at least one connection.

Is this really needed? Using max_slave_connections=0 already behaves exactly like this. Looks like the fixed issue hasn't been linked to this one: MXS-3536

Can you fix the bug in the previous comment? then it might work.

Since MXS-3536 is fixed in 2.5.12 and this should be redundant, OK if we close this?