From 065e2527679c6f8f896ac028f8effd07cdea4369 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Tue, 22 Sep 2015 07:36:26 +0300 Subject: [PATCH] Removed redundant text from documentation. --- .../Getting-Started/Configuration-Guide.md | 89 ++----------------- 1 file changed, 9 insertions(+), 80 deletions(-) diff --git a/Documentation/Getting-Started/Configuration-Guide.md b/Documentation/Getting-Started/Configuration-Guide.md index cf2770a11..c3a608b2d 100644 --- a/Documentation/Getting-Started/Configuration-Guide.md +++ b/Documentation/Getting-Started/Configuration-Guide.md @@ -736,6 +736,12 @@ Parsing within the router adds overhead to the cost of routing and makes this ty Currently a small number of query routers are available, these are in different stages of completion and offer different facilities. +* [ReadConnRoute](../Routers/ReadConnRoute.md) +* [ReadWriteSplit](../Routers/ReadWriteSplit.md) +* [SchemaRouter](../Routers/SchemaRouter.md) + +In addition to these routing modules, the binlogrouter module can act as a binary log proxy between a master and slave servers. + #### Readconnroute This is a connection based query router that was originally targeted at environments in which the clients already performed splitting of read and write queries into separate connections. @@ -926,86 +932,7 @@ The router stores all of the executed session commands so that in case of a slav Read/Write Split router-specific settings are specified in the configuration file of MaxScale in its specific section. The section can be freely named but the name is used later as a reference from listener section. -The configuration consists of mandatory and optional parameters. - -###### Mandatory parameters - -**`type`** specifies the type of service. For **readwritesplit** module the type is `router`: - - type=router - -**`service`** specifies the router module to be used. For **readwritesplit** the value is `readwritesplit`: - - service=readwritesplit - -**`servers`** provides a list of servers, which must include one master and available slaves: - - servers=server1,server2,server3 - -**NOTE: Each server on the list must have its own section in the configuration file where it is defined.** - -**`user`** is the username the router session uses for accessing backends in order to load the content of the `mysql.user` table (and `mysql.db` and database names as well) and optionally for creating, and using `maxscale_schema.replication_heartbeat` table. - -**`passwd`** specifies corresponding password for the user. Syntax for user and passwd is: - -``` -user= -passwd= -``` - -###### Optional parameters - -**`max_slave_connections`** sets the maximum number of slaves a router session uses at any moment. Default value is `1`. - - max_slave_connections= - -**`max_slave_replication_lag`** specifies how many seconds a slave is allowed to be behind the master. If the lag is bigger than configured value a slave can't be used for routing. - - max_slave_replication_lag= - -This applies to Master/Slave replication with MySQL monitor and `detect_replication_lag=1` options set. -Please note max_slave_replication_lag must be greater than monitor interval. - -**`router_options`** may include multiple **readwritesplit**-specific options. Values are either singular or parameter-value pairs. Currently available is a single option which specifies the criteria used in slave selection both in initialization of router session and per each query. Note that due to the current monitor implementation, the value specified here should be ** + 1. - - options=slave_selection_criteria= - -where ** is one of the following: - -* `LEAST_GLOBAL_CONNECTIONS`, the slave with least connections in total -* `LEAST_ROUTER_CONNECTIONS`, the slave with least connections from this router -* `LEAST_BEHIND_MASTER`, the slave with smallest replication lag -* `LEAST_CURRENT_OPERATIONS` (default), the slave with least active operations - -**`use_sql_variables_in`** specifies where should queries, which read session variable, be routed. The syntax for `use_sql_variable_in` is: - - use_sql_variables_in=[master|all] - -When value all is used, queries reading session variables can be routed to any available slave (depending on selection criteria). Note, that queries modifying session variables are routed to all backend servers by default, excluding write queries with embedded session variable modifications, such as: - - INSERT INTO test.t1 VALUES (@myid:=@myid+1) - -In above-mentioned case the user-defined variable would only be updated in the master where query would be routed due to `INSERT` statement. - -**`max_sescmd_history`** sets a limit on how many session commands each session can execute before the connection is closed. The default is an unlimited number of session commands. - - max_sescmd_history=1500 - -When a limitation is set, it effectively creates a cap on the session's memory consumption. This might be useful if connection pooling is used and the sessions use large amounts of session commands. - -**`disable_sescmd_history`** disables the session command history. This way nothing is stored and if a slave server fails and a new one is taken in its stead, the session on that server will be in an inconsistent state compared to the master server. Disabling session command history will allow connection pooling without causing a constant growth in the memory consumption. - -``` -# Disable the session command history -disable_sescmd_history=true -``` - -**`disable_slave_recovery`** disables the recovery and replacement of slave servers. If this option is enabled and a connection to a slave server in use is lost, no replacement slave will be taken. This allows the safe use of session state modifying statements when the session command history is disabled. This is mostly intended to be used with the `disable_sescmd_history` option enabled. - -``` -# Disable the session command history -disable_slave_recovery=true -``` +The configuration consists of mandatory and optional parameters. For a complete list of these, please read the [ReadWriteSplit](../Routers/ReadWriteSplit.md) documentation. An example of Read/Write Split router configuration : @@ -1024,6 +951,8 @@ filters=qla|fetch|from In addition to this, readwritesplit needs configuration for a listener, for all servers listed, and for each filter. Listener, server - and filter configurations are described in their own sections in this document. +An important parameter is the `max_slave_connections=50%` parameter. This sets the number of slaves each client connection will use. With the default values, client connections will only use a single slave for reads. For example, setting the parameter value to 100% will use all available slaves and read queries will be balanced evenly across all slaves. Changing the `max_slave_conections` parameter and `slave_selection_criteria` router option allows you to change the way MaxScale will balance reads. For more information about the `slave_selection_criteria` router option, please read the ReadWriteSplit documentation. + Below is a listener example for the "RWSplit Service" defined above: ```