Fixed spelling mistakes in documentation.
This commit is contained in:
parent
1433d28f5f
commit
327c29849c
@ -10,7 +10,7 @@ These are the changes introduced in the next MaxScale version. This is not the o
|
||||
|
||||
## MaxScale 1.1.1
|
||||
|
||||
* Schemarouter now also allows for an upper limit to session commans.
|
||||
* Schemarouter now also allows for an upper limit to session commands.
|
||||
* Schemarouter correctly handles SHOW DATABASES responses that span multiple buffers.
|
||||
* Readwritesplit and Schemarouter now allow disabling of the session command history.
|
||||
|
||||
|
@ -4,19 +4,19 @@ This document is designed with a developer's point-of-view in mind. It explains
|
||||
|
||||
## Source Files and Data Structures
|
||||
|
||||
The schemarouter router consists of the schemarouter.h header file located in the `server/modules/include/` directory and the schemarouter.c file located in the `server/modules/routing/schemarouter` directory. This router implements the router interface defined in the router.h file. The entry points and structures this router uses can be found in the header file. The two main structures in use are the router instace and router session structures. The router instance structure is defined in `struct router_instance` and the router session structure in `struct router_client_session`.
|
||||
The schemarouter router consists of the schemarouter.h header file located in the `server/modules/include/` directory and the schemarouter.c file located in the `server/modules/routing/schemarouter` directory. This router implements the router interface defined in the router.h file. The entry points and structures this router uses can be found in the header file. The two main structures in use are the router instance and router session structures. The router instance structure is defined in `struct router_instance` and the router session structure in `struct router_client_session`.
|
||||
|
||||
The definitions of the external functions and all the internal functions of the router can be found in the schemarouter.c file.
|
||||
|
||||
## Router Lifecycle
|
||||
|
||||
When MaxScale first starts, it creates all services and thus creates the router instances of all the routers. The functions involved in this stage are ModuleInit, which is called only once when MaxScale first starts, and createInstance, called for each individual instace of this router in all the configured services. These functions read configuraion values and initialize internal data.
|
||||
When MaxScale first starts, it creates all services and thus creates the router instances of all the routers. The functions involved in this stage are ModuleInit, which is called only once when MaxScale first starts, and createInstance, called for each individual instance of this router in all the configured services. These functions read configuration values and initialize internal data.
|
||||
|
||||
When a user connects to MaxScale, a new session is created and the newSession function is called. At this point the client session connects to all the backend servers and initializes the list of databases.
|
||||
|
||||
After the session is created queries are routed to the router's routeQuery function. This is where most of the work regarding the resolution of query destinations is done. This router parses the incoming buffers for full SQL packets first and routes each of them individually. The main internal functions involved in routing the query are get_shard_route_target (detects if a query needs to be sent to all the servers or to a specific one), get_shard_target_name (parses the query and finds the name of the right server) and route_session_write (handles sending and and storing session commands). After this point the client's query has been sent to the backend server and the router waits for either an response or an error signaling that the backend server is not responding.
|
||||
|
||||
If a response is received the clientReply function is called and response is simply sent to the client and the router is then ready for more queries. If there is no response from the server and the connection to it is lost the handleError function is called. This function tries to find replacement servers for the failed ones and regenerates the list of databases. This also triggeres the sending of an error packet to the client that notifies that the server is not responding.
|
||||
If a response is received the clientReply function is called and response is simply sent to the client and the router is then ready for more queries. If there is no response from the server and the connection to it is lost the handleError function is called. This function tries to find replacement servers for the failed ones and regenerates the list of databases. This also triggers the sending of an error packet to the client that notifies that the server is not responding.
|
||||
|
||||
After the session ends the closeSession is called where the session is set to a closed state after which the freeSession is called where the final freeing of memory is done. After this point the router's session has gone through all the stages of its lifecycle.
|
||||
|
||||
|
@ -50,7 +50,7 @@
|
||||
## Routers
|
||||
|
||||
- [Read Write Split](Routers/ReadWriteSplit.md)
|
||||
- [Read Connnection Router](Routers/ReadConnRoute.md)
|
||||
- [Read Connection Router](Routers/ReadConnRoute.md)
|
||||
- [Schemarouter](Routers/SchemaRouter.md)
|
||||
|
||||
## Filters
|
||||
|
@ -14,7 +14,7 @@ The **RabbitMQ Consumer Client** only has one command line argument.
|
||||
|
||||
## Installation
|
||||
|
||||
To install the RabbitMQ Consumer Client you ca either use the provided packages or you can compile it from source code. The source code is included as a part of the MaxScale source code and can be found in the `rabbtmq_consumer` folder. Please refer to the [README](../../rabbitmq_consumer/README) in the folder for more detailed instructions about installation and configuration.
|
||||
To install the RabbitMQ Consumer Client you ca either use the provided packages or you can compile it from source code. The source code is included as a part of the MaxScale source code and can be found in the `rabbitmq_consumer` folder. Please refer to the [README](../../rabbitmq_consumer/README) in the folder for more detailed instructions about installation and configuration.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
@ -68,7 +68,7 @@ user=john
|
||||
|
||||
### `log_file`
|
||||
|
||||
The optional log_file parameter defines a log file in which the filter writes all queries that are not mached and maching queries with their replacement queries. All sessions will log to this file so this should only be used for diagnostic purposes.
|
||||
The optional log_file parameter defines a log file in which the filter writes all queries that are not matched and matching queries with their replacement queries. All sessions will log to this file so this should only be used for diagnostic purposes.
|
||||
|
||||
```
|
||||
log_file=/tmp/regexfilter.log
|
||||
|
@ -978,7 +978,7 @@ 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.
|
||||
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_connections` 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:
|
||||
|
||||
|
@ -1837,7 +1837,7 @@ MariaDB Corporation MaxScale /home/jdoe/bin/develop/log/skygw_msg1.log Tue Dec
|
||||
|
||||
### Trace log
|
||||
|
||||
Trace log includes information about available servers and their states, client sessions, queries being executed, routing decisions and other routing related data. Trace log can be found from the same directory with other logs but it is physically stored elsewhere, to OSs shared memory to reduce the latency caused by logging. The location of physical file is : /dev/shm/<pid>/skygw_traceX.log where ‘X’ is the same sequence number as in the file name in the /var/log/maxscale directory.
|
||||
Trace log includes information about available servers and their states, client sessions, queries being executed, routing decisions and other routing related data. Trace log can be found from the same directory with other logs but it is physically stored elsewhere, to OS's shared memory to reduce the latency caused by logging. The location of physical file is : /dev/shm/<pid>/skygw_traceX.log where ‘X’ is the same sequence number as in the file name in the /var/log/maxscale directory.
|
||||
|
||||
Individual trace log entry looks similar to those in other logs but there is some difference too. Some log entries include a number within square brackets to specify which client session they belong to. For example:
|
||||
|
||||
|
@ -29,7 +29,7 @@ The client connection will need to have comments enabled. For example the `mysql
|
||||
For comment types, use either `-- ` (notice the whitespace) or `#` after the semicolon or `/* .. */` before the semicolon. All comment types work with routing hints.
|
||||
|
||||
The MySQL manual doesn`t specify if comment blocks, i.e. `/* .. */`, should contain a w
|
||||
hitespace character before or after the tags, so adding whitespace at both the start and the end is advised.
|
||||
whitespace character before or after the tags, so adding whitespace at both the start and the end is advised.
|
||||
|
||||
## Hint body
|
||||
|
||||
|
@ -318,7 +318,7 @@ The script exit code for "status" is 0
|
||||
|
||||
Note: the MaxScale script is LSB compatible and returns the proper exit code for each action:
|
||||
|
||||
For additional informations;
|
||||
For additional information;
|
||||
|
||||
[http://www.linux-ha.org/wiki/LSB_Resource_Agents](http://www.linux-ha.org/wiki/LSB_Resource_Agents)
|
||||
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
This document guides you in setting up multiple MaxScale instances and synchronizing the configuration files with lsyncd. Lsyncd is a rsync wrapper which can synchronize files across the network. The lsyncd daemon uses a configuration file to control the files to synchronize and the remote targets where these files are synchronized to.
|
||||
|
||||
Copying the configuration file and running the lsyncd daemon on all the hosts keeps all the configuration files in sync. Modifications in the configuration file on one of the hosts will be copied on the other hosts. This allows adinistrators to easily provide a highly available, disaster resistant MaxScale installation with up-to-date configuration files on all the hosts.
|
||||
Copying the configuration file and running the lsyncd daemon on all the hosts keeps all the configuration files in sync. Modifications in the configuration file on one of the hosts will be copied on the other hosts. This allows administrators to easily provide a highly available, disaster resistant MaxScale installation with up-to-date configuration files on all the hosts.
|
||||
|
||||
### Requirements
|
||||
You will need:
|
||||
@ -127,9 +127,9 @@ The most important part is the `sync` section which defines a target for synchro
|
||||
|
||||
The `source` parameter tells lsyncd where to read the files from. This should be the location of the maxscale.cnf file. The `host` parameter defines the host where the files should be synchronized to and the user account lsyncd should use when synchronizing the files. The `targetdir` parameter defines the local directory on the remote target where the files should be synchronized to. This value should be the location on the remote host where the maxscale.cnf file is searched from. By default, this is the `/etc` folder.
|
||||
|
||||
The optional `ssh` parameter and its sub-parameter `port`define a custom port for the SSH connection. Most users do not need this parameterer. The `rsycn` parameter contains an arra of options that are passed to the rsycn executable. These should not be changed unless you specifically know what you are doing. For more information on the options passed to rsync read the rsync(1) manpage.
|
||||
The optional `ssh` parameter and its sub-parameter `port`define a custom port for the SSH connection. Most users do not need this parameter. The `rsycn` parameter contains an array of options that are passed to the rsycn executable. These should not be changed unless you specifically know what you are doing. For more information on the options passed to rsync read the rsync(1) manpage.
|
||||
|
||||
You can add multiple remote targets by defining multiple `sync` sections. Here is an example with two sync sections defining different hosts that have MaxScale installed and whose configuration files should be kep in sync.
|
||||
You can add multiple remote targets by defining multiple `sync` sections. Here is an example with two sync sections defining different hosts that have MaxScale installed and whose configuration files should be kept in sync.
|
||||
|
||||
```
|
||||
settings{
|
||||
@ -167,7 +167,7 @@ rsync={
|
||||
|
||||
## Starting Lsyncd
|
||||
|
||||
Starting lsyncd can be done from the command line or through a init script. To start syncd from the command like, execute the `lsyncd` command and pass the configuration file as the only parameter.
|
||||
Starting lsyncd can be done from the command line or through a init script. To start lsyncd from the command like, execute the `lsyncd` command and pass the configuration file as the only parameter.
|
||||
|
||||
By default lsyncd will search for the configuration file in `/etc/lsyncd.conf`. By placing the configuration file we created in the `/etc` folder, we can start lsyncd with the following command.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Readconnroute
|
||||
|
||||
This document provides anoverview of the **readconnroute** router module and its intended use case scenarios. It also displays all router configuration parameters with their descriptions.
|
||||
This document provides an overview of the **readconnroute** router module and its intended use case scenarios. It also displays all router configuration parameters with their descriptions.
|
||||
|
||||
## Overview
|
||||
|
||||
@ -63,7 +63,7 @@ servers=server1,server2
|
||||
weightby=serv_weight
|
||||
```
|
||||
|
||||
With this configuration and a heavy query load, the server *server1* will get most of the connections and about a third of the remaining queries are routed to the second server. With server weights, you can assing secondary servers that are only used when the primary server is under heavy load.
|
||||
With this configuration and a heavy query load, the server *server1* will get most of the connections and about a third of the remaining queries are routed to the second server. With server weights, you can assign secondary servers that are only used when the primary server is under heavy load.
|
||||
|
||||
Without the weightby parameter, each connection counts as a single connection. With a weighting parameter, a single connection received its weight from the server's own weighting parameter divided by the sum of all weighting parameters in all the configured servers.
|
||||
|
||||
|
@ -223,5 +223,5 @@ To bring the server back into service use the "clear server" command to clear th
|
||||
MaxScale> clear server dbserver3 maintenance
|
||||
MaxScale>
|
||||
```
|
||||
Note that maintenance mode is not persistent, if MaxScale restarts when a node is in maintenance mode a new instance of MaxScale will not honour this mode. If multiple MaxScale instances are configured to use the node them maintenance mode must be set within each MaxScale instance. However if multiple services within one MaxScale instance are using the server then you only need set the maintenance mode once on the server for all services to take note of the mode change.
|
||||
Note that maintenance mode is not persistent, if MaxScale restarts when a node is in maintenance mode a new instance of MaxScale will not honor this mode. If multiple MaxScale instances are configured to use the node them maintenance mode must be set within each MaxScale instance. However if multiple services within one MaxScale instance are using the server then you only need set the maintenance mode once on the server for all services to take note of the mode change.
|
||||
|
||||
|
@ -154,7 +154,7 @@ This monitor module will assign one node within the Galera Cluster as the curren
|
||||
[Galera Monitor]
|
||||
type=monitor
|
||||
module=galeramon
|
||||
diable_master_failback=1
|
||||
disable_master_failback=1
|
||||
servers=dbserv1, dbserv2, dbserv3
|
||||
user=maxscale
|
||||
passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
|
@ -150,7 +150,7 @@ port=3306
|
||||
socket=/tmp/ClusterMaster
|
||||
```
|
||||
|
||||
An address parameter may be given if the listener is required to bind to a particular network address when using hosts with multiple network addresses. The default behaviour is to listen on all network interfaces.
|
||||
An address parameter may be given if the listener is required to bind to a particular network address when using hosts with multiple network addresses. The default behavior is to listen on all network interfaces.
|
||||
|
||||
The next stage is the configuration is to define the server information. This defines how to connect to each of the servers within the cluster, again a section is created for each server, with the type set to server, the network address and port to connect to and the protocol to use to connect to the server. Currently the protocol module for all database connections in MySQLBackend.
|
||||
```
|
||||
|
@ -29,7 +29,7 @@ While MaxScale resources and status can be monitored via CLI using maxadmin comm
|
||||

|
||||
|
||||
|
||||
There are three nagios plugin scripts that MaxScale provides.
|
||||
There are three Nagios plugin scripts that MaxScale provides.
|
||||
|
||||
1. check_maxscale_threads.pl: This command provides you the status of current running threads and events in the queue on MaxScale Server. The Performance data associated with this command current and historic wait time for threads and events
|
||||
|
||||
@ -38,7 +38,7 @@ Current resources are: modules, services, listeners, servers, sessions, filters.
|
||||
|
||||
3. check_maxscale_monitor.pl: This command provides you status of the configured monitor modules on MaxScale server.
|
||||
|
||||
In order to use these scripts on your Nagios Server, you need to copy them from the MaxScale binary package or download them from source tree on github.
|
||||
In order to use these scripts on your Nagios Server, you need to copy them from the MaxScale binary package or download them from source tree on GitHub.
|
||||
|
||||
# MaxScale Nagios Plugin Requirements
|
||||
|
||||
|
@ -53,7 +53,7 @@ MaxScale generates the feedback report containing following information:
|
||||
- MaxScale Version
|
||||
- An identifier of the MaxScale installation, i.e. the HEX encoding of SHA1 digest of the first network interface MAC address
|
||||
- Operating System (i.e Linux)
|
||||
- Operating Suystem Distribution (i.e. CentOS release 6.5 (Final))
|
||||
- Operating System Distribution (i.e. CentOS release 6.5 (Final))
|
||||
- All the modules in use in MaxScale and their API and version
|
||||
- MaxScale server UNIX_TIME at generation time
|
||||
|
||||
|
@ -364,7 +364,7 @@ If the consumer.cnf file is not in the same directory as the binary file is, you
|
||||
# ./consumer -c path/to/file
|
||||
```
|
||||
|
||||
and start maxScale as well
|
||||
and start MaxScale as well
|
||||
|
||||
## Step 6 - Test the filter and check collected data
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user