Moved all limitations to Limitations.md
This removes duplicate information and keeps the list of limitations in a central place.
This commit is contained in:
Markus Makela
parent
c93d2d37f4
commit
e2588e3c95
@ -22,9 +22,7 @@ The default master selection is based only on MIN(wsrep_local_index). This can b
|
||||
|
||||
## Limitations in the Read/Write Splitter
|
||||
|
||||
### Scale-out limitations
|
||||
|
||||
In master-slave replication cluster also read-only queries are routed to master too in the following situations:
|
||||
Read queries are routed to the master server in the following situations:
|
||||
|
||||
* if they are executed inside an open transaction
|
||||
|
||||
@ -32,13 +30,27 @@ In master-slave replication cluster also read-only queries are routed to master
|
||||
|
||||
* statement includes a stored procedure, or an UDF call
|
||||
|
||||
### Multi-statement limitations
|
||||
* if there are multiple statements inside one query e.g. `INSERT INTO ... ; SELECT LAST_INSERT_ID();`
|
||||
|
||||
If the client enables and executes multi-statements, they will be routed to
|
||||
the master. All future queries will also be routed to the master to guarantee
|
||||
a consistent session state after the multi-statement query. This behavior can
|
||||
be controlled with the `strict_multi_stmt` router option. For more information,
|
||||
read the [ReadWriteSplit](../Routers/ReadWriteSplit.md) router documentation.
|
||||
### Limitations in multi-statement handling
|
||||
|
||||
When a multi-statemet query is executed through the readwritesplit router, it will always
|
||||
be routed to the master. With the default configuration, all queries after a
|
||||
multi-statement query will be routed to the master to prevent possible reads of
|
||||
false data.
|
||||
|
||||
You can override this behavior with the `strict_multi_stmt=false`
|
||||
router option. In this mode, the multi-statement queries will still be routed
|
||||
to the master but individual statements are routed normally. If you use
|
||||
multi-statements and you know they don't modify the session state in any
|
||||
relevant way, you can disable this option for better performance.
|
||||
|
||||
For more information, read the [ReadWriteSplit](../Routers/ReadWriteSplit.md) router documentation.
|
||||
|
||||
### Parsing related limitations
|
||||
|
||||
Galera Cluster variables, such as @@wsrep_node_name, are not resolved by
|
||||
the embedded MariaDB parser. This usually means that the query will be routed to the master.
|
||||
|
||||
### Limitations in client session handling
|
||||
|
||||
@ -98,4 +110,51 @@ Most imaginable reasons are related to replication lag but it could be possible
|
||||
|
||||
## Authentication Related Limitations
|
||||
|
||||
MySQL old style passwords are not supported. MySQL versions 4.1 and newer use a new authentication protocol which does not support pre-4.1 style passwords.
|
||||
* MaxScale can not manage authentication that uses wildcard matching in hostnames
|
||||
in the mysql.user table of the backend database. The only wildcards that can be
|
||||
used are in IP address entries.
|
||||
|
||||
* MySQL old style passwords are not supported. MySQL versions 4.1 and newer use
|
||||
a new authentication protocol which does not support pre-4.1 style passwords.
|
||||
|
||||
* When users have different passwords based on the host from which they connect
|
||||
MaxScale is unable to determine which password it should use to connect to the
|
||||
backend database. This results in failed connections and unusable usernames
|
||||
in MaxScale.
|
||||
|
||||
## Schemarouter limitations
|
||||
|
||||
The schemarouter router currently has some limitations due to the nature of
|
||||
the sharding implementation and the way the session variables are detected
|
||||
and routed. Here is a list of the current limitations.
|
||||
|
||||
* Cross-database queries (e.g. `SELECT column FROM database1.table UNION select column FROM database2.table`)
|
||||
are not supported and are routed either to the first explicit database in the query,
|
||||
the current database in use or to the first available database,
|
||||
if none of the previous conditions are met.
|
||||
|
||||
* Queries without explicit databases that are not session commands
|
||||
in them are either routed to the current or the first available
|
||||
database. This means that, for example when creating a new database,
|
||||
queries should be done directly on the node or the router should
|
||||
be equipped with the hint filter and a routing hint should be used.
|
||||
|
||||
* Temporary tables are only created on the explicit database in the query
|
||||
or the current database in use. If no database is in use and no database
|
||||
is explicitly stated, the behavior of the router is undefined.
|
||||
|
||||
* SELECT queries that modify session variables are not currently supported
|
||||
because uniform results can not be guaranteed. If such a query is
|
||||
executed, the behavior of the router is undefined. To work around this
|
||||
limitation the query must be executed in separate parts.
|
||||
|
||||
* Queries targeting databases not mapped by the schemarouter router but
|
||||
still exist on the database server are not blocked but routed to
|
||||
the first available server. This possibly returns an error about
|
||||
database rights instead of a missing database. The behavior of
|
||||
the router is undefined in this case.
|
||||
|
||||
## Dbfwfilter limitations
|
||||
|
||||
The Database Firewall filter does not support multi-statements. Using them
|
||||
will result in an error being sent to the client.
|
||||
|
||||
@ -52,25 +52,8 @@ MaxScale no longer supports SSLv3.
|
||||
|
||||
## Known Issues and Limitations
|
||||
|
||||
There are some limitations within this version of MaxScale,
|
||||
the most serious of this are listed below.
|
||||
|
||||
* MaxScale can not manage authentication that uses wildcard matching in hostnames
|
||||
in the mysql.user table of the backend database. The only wildcards that can be
|
||||
used are in IP address entries.
|
||||
|
||||
* When users have different passwords based on the host from which they connect
|
||||
MaxScale is unable to determine which password it should use to connect to the
|
||||
backend database. This results in failed connections and unusable usernames
|
||||
in MaxScale.
|
||||
|
||||
* The readconnroute module does not support sending of LONGBLOB data.
|
||||
|
||||
* Galera Cluster variables, such as @@wsrep_node_name, are not resolved by
|
||||
the embedded MariaDB parser.
|
||||
|
||||
* The Database Firewall filter does not support multi-statements. Using them
|
||||
will result in an error being sent to the client.
|
||||
There are some limitations and known issues within this version of MaxScale.
|
||||
For more information, please refer to the [Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Packaging
|
||||
|
||||
|
||||
@ -102,3 +102,7 @@ A complete example of a service entry for a binlog router service would be as fo
|
||||
```
|
||||
|
||||
The minimum set of router options that must be given in the configuration are are server-id and master-id, default values may be used for all other options.
|
||||
|
||||
## Examples
|
||||
|
||||
The [Replication Proxy](../Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md) tutorial will show you how to configure and administrate a binlogrouter installation.
|
||||
|
||||
@ -21,4 +21,4 @@ address=localhost
|
||||
port=6603
|
||||
```
|
||||
|
||||
Note that this uses the default port of 6603 and confines the connections to localhost connections only. Remove the address= entry to allow connections from any machine on your network. Changing the port from 6603 will mean that you must allows pass a -p option to the MaxAdmin command.
|
||||
Note that this uses the default port of 6603 and confines the connections to localhost connections only. Remove the address= entry to allow connections from any machine on your network. Changing the port from 6603 will mean that you must always pass a -P option to the maxadmin command.
|
||||
|
||||
@ -69,6 +69,8 @@ Without the weightby parameter, each connection counts as a single connection. W
|
||||
|
||||
If we use the previous configuration as an example, the sum of the `serv_weight` parameter is 4. Server1 would receive a weight of `3/4=75%` and server2 would get `1/4=25%`. This means that server1 would get 75% of the connections and server2 would get 25% of the connections.
|
||||
|
||||
## Router Options
|
||||
|
||||
**`router_options`** can contain a list of valid server roles. These roles are used as the valid types of servers the router will form connections to when new sessions are created.
|
||||
```
|
||||
router_options=slave
|
||||
@ -85,6 +87,10 @@ running|A server that is up and running. All servers that MaxScale can connect t
|
||||
|
||||
If no `router_options` parameter is configured in the service definition, the router will use the default value of `running`. This means that it will load balance connections across all running servers defined in the `servers` parameter of the service.
|
||||
|
||||
## Limitations
|
||||
|
||||
For a list of readconnroute limitations, please read the [Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Examples
|
||||
|
||||
The most common use for the readconnroute is to provide either a read or write port for an application. This provides a more lightweight routing solution than the more complex readwritesplit router but requires the application to be able to use distinct write and read ports.
|
||||
|
||||
@ -165,81 +165,7 @@ The readwritesplit router supports routing hints. For a detailed guide on hint s
|
||||
|
||||
## Limitations
|
||||
|
||||
In Master-Slave replication cluster also read-only queries are routed to master too in the following situations:
|
||||
|
||||
* if they are executed inside an open transaction
|
||||
|
||||
* in case of prepared statement execution
|
||||
|
||||
* statement includes a stored procedure, or an UDF call
|
||||
|
||||
* if there are multiple statements inside one query e.g. `INSERT INTO ... ; SELECT LAST_INSERT_ID();`
|
||||
|
||||
### Limitations in multi-statement handling
|
||||
|
||||
When a multi-statemet query is executed through the readwritesplit router, it will always
|
||||
be routed to the master. With the default configuration, all queries after a
|
||||
multi-statement query will be routed to the master to prevent possible reads of
|
||||
false data. You can override this behavior with the `strict_multi_stmt=false`
|
||||
router option. In this mode, the multi-statement queries will still be routed
|
||||
to the master but individual statements are routed normally. If you use
|
||||
multi-statements and you know they don't modify the session state in any
|
||||
relevant way, you can disable this option for better performance.
|
||||
|
||||
### Limitations in client session handling
|
||||
|
||||
Some of the queries that client sends are routed to all backends instead of sending them just to one of server. These queries include `USE <db name>` and `SET autocommit=0` among many others. Readwritesplit sends a copy of these queries to each backend server and forwards the master's reply to the client. Below is a list of MySQL commands which are classified as session commands :
|
||||
```
|
||||
COM_INIT_DB (USE <db name> creates this)
|
||||
|
||||
COM_CHANGE_USER
|
||||
|
||||
COM_STMT_CLOSE
|
||||
|
||||
COM_STMT_SEND_LONG_DATA
|
||||
|
||||
COM_STMT_RESET
|
||||
|
||||
COM_STMT_PREPARE
|
||||
|
||||
COM_QUIT (no response, session is closed)
|
||||
|
||||
COM_REFRESH
|
||||
|
||||
COM_DEBUG
|
||||
|
||||
COM_PING
|
||||
|
||||
SQLCOM_CHANGE_DB (USE ... statements)
|
||||
|
||||
SQLCOM_DEALLOCATE_PREPARE
|
||||
|
||||
SQLCOM_PREPARE
|
||||
|
||||
SQLCOM_SET_OPTION
|
||||
|
||||
SELECT ..INTO variable|OUTFILE|DUMPFILE
|
||||
|
||||
SET autocommit=1|0
|
||||
```
|
||||
|
||||
There is a possibility for misbehavior; if `USE mytable` was executed in one of the slaves and it failed, it may be due to replication lag rather than the fact it didn’t exist. Thus the same command may end up with different result among backend servers. The slaves which fail to execute a session command will be dropped from the active list of slaves for this session to guarantee a consistent session state across all the servers that are in use by the session.
|
||||
|
||||
The above-mentioned behavior can be partially controller with the `use_sql_variables_in` configuration parameter.
|
||||
|
||||
```
|
||||
use_sql_variables_in=[master|all] (master)
|
||||
```
|
||||
|
||||
Server-side session variables are called as SQL variables. If "master" or no value is set, SQL variables are read and written in master only. Autocommit values and prepared statements are routed to all nodes always.
|
||||
|
||||
**NOTE**: If variable is written as a part of write query, it is treated like write query and not routed to all servers. For example, `INSERT INTO test.t1 VALUES (@myvar:= 7)` will be routed to the master and an error in the error log will be written.
|
||||
|
||||
### Examples of limitations
|
||||
|
||||
If new database "db" was created and client executes “USE db” and it is routed to slave before the CREATE DATABASE clause is replicated to all slaves there is a risk of executing query in wrong database. Similarly, if any response that RWSplit sends back to the client differ from that of the master, there is a risk for misbehavior. To prevent this, any failures in session command execution are treated as fatal errors and all connections by the session to that particular slave server will be closed. In addition, the server will not used again for routing for the duration of the session.
|
||||
|
||||
Most imaginable reasons are related to replication lag but it could be possible that a slave fails to execute something because of some non-fatal, temporary failure while execution of same command succeeds in other backends.
|
||||
For a list of readwritesplit limitations, please read the [Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@ -55,17 +55,7 @@ The schemarouter supports the following router options:
|
||||
|
||||
## Limitations
|
||||
|
||||
The schemarouter router currently has some limitations due to the nature of the sharding implementation and the way the session variables are detected and routed. Here is a list of the current limitations.
|
||||
|
||||
- Cross-database queries (e.g. `SELECT column FROM database1.table UNION select column FROM database2.table`) are not supported and are routed either to the first explicit database in the query, the current database in use or to the first available database, if none of the previous conditions are met.
|
||||
|
||||
- Queries without explicit databases that are not session commands in them are either routed to the current or the first available database. This means that, for example when creating a new database, queries should be done directly on the node or the router should be equipped with the hint filter and a routing hint should be used.
|
||||
|
||||
- Temporary tables are only created on the explicit database in the query or the current database in use. If no database is in use and no database is explicitly stated, the behavior of the router is undefined.
|
||||
|
||||
- SELECT queries that modify session variables are not currently supported because uniform results can not be guaranteed. If such a query is executed, the behavior of the router is undefined. To work around this limitation the query must be executed in separate parts.
|
||||
|
||||
- Queries targeting databases not mapped by the schemarouter router but still exist on the database server are not blocked but routed to the first available server. This possibly returns an error about database rights instead of a missing database. The behavior of the router is undefined in this case.
|
||||
For a list of schemarouter limitations, please read the [Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user