From 786f34cf49a4e5fd67d27cbbdee96cd5aa4e6461 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Tue, 14 Apr 2015 20:36:29 +0300 Subject: [PATCH] Fixed typos in documentation. --- Documentation/About/About-MaxScale.md | 2 +- Documentation/About/SETUP.md | 2 +- .../Getting-Started/Configuration-Guide.md | 10 ++++----- .../Getting-Started-With-MaxScale.md | 2 +- .../Reference/Debug-And-Diagnostic-Support.md | 22 +++++++++---------- .../How-errors-are-handled-in-MaxScale.md | 2 +- Documentation/Reference/MaxAdmin.md | 10 ++++----- .../MaxScale-HA-with-Corosync-Pacemaker.md | 4 ++-- .../Tutorials/Administration-Tutorial.md | 4 ++-- ...era-Cluster-Connection-Routing-Tutorial.md | 6 ++--- ...a-Cluster-Read-Write-Splitting-Tutorial.md | 6 ++--- .../Tutorials/MaxScale-Information-Schema.md | 2 +- .../Tutorials/MySQL-Cluster-Setup.md | 2 +- ...Replication-Connection-Routing-Tutorial.md | 4 ++-- ...plication-Read-Write-Splitting-Tutorial.md | 2 +- .../Tutorials/Notification-Service.md | 4 ++-- ...eplication-Proxy-Binlog-Router-Tutorial.md | 6 ++--- .../Tutorials/Simple-Sharding-Tutorial.md | 2 +- .../filters/Database-Firewall-Filter.md | 2 +- .../filters/RabbitMQ-Consumer-Client.md | 4 ++-- Documentation/filters/RabbitMQ-Filter.md | 2 +- Documentation/filters/Regex-Filter.md | 2 +- Documentation/filters/Tee-Filter.md | 2 +- Documentation/filters/Top-N-Filter.md | 8 +++---- README | 4 ++-- etc/DESCRIPTION | 4 ++-- 26 files changed, 60 insertions(+), 60 deletions(-) diff --git a/Documentation/About/About-MaxScale.md b/Documentation/About/About-MaxScale.md index 496ca8d5b..d2d133414 100644 --- a/Documentation/About/About-MaxScale.md +++ b/Documentation/About/About-MaxScale.md @@ -1,7 +1,7 @@ # About MaxScale The MariaDB Corporation **MaxScale** is an intelligent proxy that allows forwarding of database statements to one or more database servers using complex rules, which can be based on a semantic understanding of the database statements and the roles of the various servers within the backend cluster of databases. -MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides a highly scalable and flexibile architecture, with plugin components to support different protocols and routing decisions. +MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides a highly scalable and flexible architecture, with plugin components to support different protocols and routing decisions. MaxScale is implemented in C so as to operate speedily. It also makes extensive use of the asynchronous I/O capabilities of the Linux operating system. The epoll system is used to provide the event driven framework for the input and output via sockets. Similar features in Windows® could be used in future development of MaxScale. diff --git a/Documentation/About/SETUP.md b/Documentation/About/SETUP.md index d391b68fd..2be316a4d 100644 --- a/Documentation/About/SETUP.md +++ b/Documentation/About/SETUP.md @@ -10,7 +10,7 @@ Simply set the environment variable MAXSCALE_HOME to point to the MaxScale directory, found inside the path into which the files have been copied, e.g. MAXSCALE_HOME=/usr/local/mariadb-maxscale -Also you will need to optionaly set LD_LIBRARY_PATH to include the 'lib' folder, +Also you will need to optionally set LD_LIBRARY_PATH to include the 'lib' folder, found inside the path into which the files have been copied, e.g. LD_LIBRARY_PATH=/usr/local/mariadb-maxscale/lib diff --git a/Documentation/Getting-Started/Configuration-Guide.md b/Documentation/Getting-Started/Configuration-Guide.md index 350b943a0..e4dc220c0 100644 --- a/Documentation/Getting-Started/Configuration-Guide.md +++ b/Documentation/Getting-Started/Configuration-Guide.md @@ -2,7 +2,7 @@ ## Introduction -The purpose of this document is to describe how to configure MaxScale and to discuss some possible usage scenarios for MaxScale. MaxScale is designed with flexibility in mind, and consists of an event processing core with various support functions and plugin modules that tailor the behaviour of the MaxScale itself. +The purpose of this document is to describe how to configure MaxScale and to discuss some possible usage scenarios for MaxScale. MaxScale is designed with flexibility in mind, and consists of an event processing core with various support functions and plugin modules that tailor the behavior of the MaxScale itself. ### Terms @@ -120,7 +120,7 @@ In order for MaxScale to forward any requests it must have at least one service #### `router` -The router parameter of a service defines the name of the router module that will be used to implement the routing algorithm between the client of MaxScale and the backend databases. Additionally routers may also be passed a comma separated list of options that are used to control the behaviour of the routing algorithm. The two parameters that control the routing choice are router and router_options. The router options are specific to a particular router and are used to modify the behaviour of the router. The read connection router can be passed options of master, slave or synced, an example of configuring a service to use this router and limiting the choice of servers to those in slave state would be as follows. +The router parameter of a service defines the name of the router module that will be used to implement the routing algorithm between the client of MaxScale and the backend databases. Additionally routers may also be passed a comma separated list of options that are used to control the behavior of the routing algorithm. The two parameters that control the routing choice are router and router_options. The router options are specific to a particular router and are used to modify the behavior of the router. The read connection router can be passed options of master, slave or synced, an example of configuring a service to use this router and limiting the choice of servers to those in slave state would be as follows. ``` router=readconnroute @@ -539,7 +539,7 @@ This protocol module is currently still under development, it provides a means t The main task of MaxScale is to accept database connections from client applications and route the connections or the statements sent over those connections to the various services supported by MaxScale. -There are two flavours of routing that MaxScale can perform, connection based routing and statement based routine. These each have their own characteristics and costs associated with them. +There are two flavors of routing that MaxScale can perform, connection based routing and statement based routine. These each have their own characteristics and costs associated with them. ### Connection Based Routing @@ -644,7 +644,7 @@ passwd=galeramon The specialized Galera monitor can also select one of the node in the cluster as _Master_, the others will be marked as _Slave_. These roles are only assigned to _Synced_ nodes. -It then possible to have services/listeners with `router_options=master` or `slave` accessing a subset of all galera nodes. The _Synced_ state simply means: access all nodes. Examples of different **readconn** router configurations for Galera: +It then possible to have services/listeners with `router_options=master` or `slave` accessing a subset of all Galera nodes. The _Synced_ state simply means: access all nodes. Examples of different **readconn** router configurations for Galera: ``` [Galera Master Service] @@ -1308,7 +1308,7 @@ In this case the user *X* would be able to connect to MaxScale from host a givin Hostname mapping in MaxScale works in exactly the same way as for MySQL, if the wildcard is used for the host then any host other than the localhost (127.0.0.1) will match. It is important to consider that the localhost check will be performed at the MaxScale level and at the MySQL server level. -If MaxScale and the databases are on separate hosts there are two important changes in behaviour to consider: +If MaxScale and the databases are on separate hosts there are two important changes in behavior to consider: 1. Clients running on the same machine as the backend database now may access the database using the wildcard entry. The localhost check between the client and MaxScale will allow the use of the wildcard, since the client is not running on the MaxScale host. Also the wildcard entry can be used on the database host as MaxScale is making that connection and it is not running on the same host as the database. diff --git a/Documentation/Getting-Started/Getting-Started-With-MaxScale.md b/Documentation/Getting-Started/Getting-Started-With-MaxScale.md index f94e47bb3..24ee54b22 100644 --- a/Documentation/Getting-Started/Getting-Started-With-MaxScale.md +++ b/Documentation/Getting-Started/Getting-Started-With-MaxScale.md @@ -65,7 +65,7 @@ modules it will search using a predescribed search path. The rules are: 2. Look in $MAXSCALE_HOME/modules 3. Look in /usr/local/mariadb-maxscale/modules -Configuration is read by default from the file $MAXSCALE_HOME/etc/MaxScale.cnf, /etc/MaxScale.cnf. An example file is included in in the installation and can be found in the etc/ folder within the MaxScale installation. The default value of MAXSCALE_HOME can be overriden by using the -c flag on the command line. This should be immediately followed by the path to the MaxScale home directory. The -f flag can be used on the command line to set the name and the location of the configuration file. Without path expression the file is read from \$MAXSCALE_HOME/etc directory. +Configuration is read by default from the file $MAXSCALE_HOME/etc/MaxScale.cnf, /etc/MaxScale.cnf. An example file is included in in the installation and can be found in the etc/ folder within the MaxScale installation. The default value of MAXSCALE_HOME can be overridden by using the -c flag on the command line. This should be immediately followed by the path to the MaxScale home directory. The -f flag can be used on the command line to set the name and the location of the configuration file. Without path expression the file is read from \$MAXSCALE_HOME/etc directory. ## Administration Of MaxScale diff --git a/Documentation/Reference/Debug-And-Diagnostic-Support.md b/Documentation/Reference/Debug-And-Diagnostic-Support.md index 8da5ec1b2..34fda6653 100644 --- a/Documentation/Reference/Debug-And-Diagnostic-Support.md +++ b/Documentation/Reference/Debug-And-Diagnostic-Support.md @@ -82,7 +82,7 @@ Beyond the language support for debugging using tools such as gdb, MaxScale will ## Command Line Option -Normally when MaxScale starts it will place itself in the background and setup the signal masks so that it is immune to the normal set of signals that will cause the process to exit, SIGINT and SIGQUIT. This behaviour is normally what is required, however if you wish to run MaxScale under the control of a debugger it is useful to suppress this behaviour. A command line option, -d is provided to turn off this behaviour. +Normally when MaxScale starts it will place itself in the background and setup the signal masks so that it is immune to the normal set of signals that will cause the process to exit, SIGINT and SIGQUIT. This behavior is normally what is required, however if you wish to run MaxScale under the control of a debugger it is useful to suppress this behavior. A command line option, -d is provided to turn off this behavior. % gdb maxscale @@ -234,7 +234,7 @@ Server 0x60d920 ### Modules -MaxScale makes significant use of moules, shared objects, that are loaded on demand based on the configuration. A routine exists that will print the currently loaded modules. +MaxScale makes significant use of modules, shared objects, that are loaded on demand based on the configuration. A routine exists that will print the currently loaded modules. (gdb) call printModules() @@ -476,7 +476,7 @@ The commands available are very similar to those described above to print things ## Listing Services -The list services command is designed to give a concise tabular view of the currently configured services within MaxScale along with key data that summarises the use beign made of the service. +The list services command is designed to give a concise tabular view of the currently configured services within MaxScale along with key data that summarizes the use being made of the service. **MaxScale>** list services @@ -830,13 +830,13 @@ Server 0x6ec5d0 (server4) * the value of ‘Ndb_cluster_node_id’ for SQL nodes in MySQL Cluster -* the -1 value for a failure getting one of these informations +* the -1 value for a failure getting one of these information * Repl Depth is the replication depth level found by MaxScale MySQL Monitor * Master Id is the master node, if available, for current server -* Slave Ids is the slave list for the current node, if availbable +* Slave Ids is the slave list for the current node, if available Note, the Master Root Server used for routing decision is the server with master role and with lowest replication depth level. All slaves servers even if they are intermediate master are suitable for read statement routing decisions. @@ -844,7 +844,7 @@ Note, the Master Root Server used for routing decision is the server with master Value of 0 or less than monitor interval means there is no replication delay. -* Last Repl Heartbeat is the maxScale timestamp read or inserted (if current server is master) +* Last Repl Heartbeat is the MaxScale timestamp read or inserted (if current server is master) The Replication Heartbeat table is updated by MySQL replication, starting MaxScale when there is a significant slave delay may result that Slave Delay and Last Repl Heartbeat are not available for some time in the slave server details @@ -1559,7 +1559,7 @@ Server 0x6ec5d0 (server4) **MaxScale>** set server 0x6ec840 slave -Valid options that are recognised by the set server command are running, master and slave. Please note that if the monitor is running it will reset the flags to match reality, this interface is really for use when the monitor is disabled. +Valid options that are recognized by the set server command are running, master and slave. Please note that if the monitor is running it will reset the flags to match reality, this interface is really for use when the monitor is disabled. In user mode there is no need to find the address of the server structure, the name of the server from the section header in the configuration file make be given. @@ -1691,7 +1691,7 @@ Note, not all configuration elements can be changed dynamically currently. This ## Add user -The add user command is used to add new users to the debug CLI of MaxScale. The default behaviour of the CLI for MaxScale is to have a login name of admin and a fixed password of mariadb. Adding new users will disable this default behaviour and limit the login access to the users that are added. +The add user command is used to add new users to the debug CLI of MaxScale. The default behavior of the CLI for MaxScale is to have a login name of admin and a fixed password of mariadb. Adding new users will disable this default behavior and limit the login access to the users that are added. **MaxScale>** add user admin july2013 @@ -1711,11 +1711,11 @@ User admin already exists. **MaxScale>**** ** -If you should forget or lose the the account details you may simply remove the passwd file in $MAXSCALE_HOME/etc and the system will revert to the default behaviour with admin/mariadb as the account. +If you should forget or lose the the account details you may simply remove the passwd file in $MAXSCALE_HOME/etc and the system will revert to the default behavior with admin/mariadb as the account. ## Enable/disable log -The enable/disable log command is used to enable/disable the log facility of MaxScale. The default behaviour for MaxScale is to have all logs enabled in DEBUG version, and only error log in production release. +The enable/disable log command is used to enable/disable the log facility of MaxScale. The default behavior for MaxScale is to have all logs enabled in DEBUG version, and only error log in production release. Examples: @@ -1741,7 +1741,7 @@ No output for these commands in the debug interface, but in the affected logs th # Logging facility -MaxScale generates output of its behavior to four distinct logs, error, messages, trace and debug log. Error and message logs are enabled by default but all logs can be dynamically enabled and disabled by using maxadm utility, debug client interface (telnet) or optionally by using your own application through the client API. +MaxScale generates output of its behavior to four distinct logs, error, messages, trace and debug log. Error and message logs are enabled by default but all logs can be dynamically enabled and disabled by using maxadmin utility, debug client interface (telnet) or optionally by using your own application through the client API. ## Log contents diff --git a/Documentation/Reference/How-errors-are-handled-in-MaxScale.md b/Documentation/Reference/How-errors-are-handled-in-MaxScale.md index 28ac113ce..adeb5e7cf 100644 --- a/Documentation/Reference/How-errors-are-handled-in-MaxScale.md +++ b/Documentation/Reference/How-errors-are-handled-in-MaxScale.md @@ -52,5 +52,5 @@ Reasons for "backend failure" in rwsplit: ### Router error -In cases where SESSION_ROUTE_QUERY has returned successfully (=1) query may not be successfully processed in backend or even sent to it. It is posible that router fails in routing the particular query but there is no such error which would prevent session from continuing. In this case router handles error silently by creating and adding MySQL error to first available backend’s (incoming) eventqueue where it is found and sent to client (clientReply). +In cases where SESSION_ROUTE_QUERY has returned successfully (=1) query may not be successfully processed in backend or even sent to it. It is possible that router fails in routing the particular query but there is no such error which would prevent session from continuing. In this case router handles error silently by creating and adding MySQL error to first available backend’s (incoming) eventqueue where it is found and sent to client (clientReply). diff --git a/Documentation/Reference/MaxAdmin.md b/Documentation/Reference/MaxAdmin.md index 7b8d6316c..b8889192a 100644 --- a/Documentation/Reference/MaxAdmin.md +++ b/Documentation/Reference/MaxAdmin.md @@ -74,7 +74,7 @@ When a switch takes a value, this may either be as the next argument on the comm If no arguments other than the command line switches are passed to MaxAdmin it will enter its interactive mode of operation. Users will be prompted to enter commands with a **MaxScale>** prompt. The commands themselves are documented in the sections later in this document. A help system is available that will give some minimal details of the commands available. -Command history is available on platforms that support the libedit library. This allows the use of the up and down arrow keys to recall previous commands that have been executed by MaxAdmin. The default edit mode for the history is to emulate the vi commands, the behaviour of libedit may however be customised using the .editrc file. To obtain the history of commands that have been executed use the inbuilt history command. +Command history is available on platforms that support the libedit library. This allows the use of the up and down arrow keys to recall previous commands that have been executed by MaxAdmin. The default edit mode for the history is to emulate the vi commands, the behavior of libedit may however be customized using the .editrc file. To obtain the history of commands that have been executed use the inbuilt history command. In interactive mode it is possible to execute a set of commands stored in an external file by using the source command. The command takes the argument of a filename which should contain a set of MaxScale commands, one per line. These will be executed in the order they appear in the file. @@ -713,7 +713,7 @@ MaxScale uses a number of threads, as defined in the MaxScale configuration file 2 | Processing | 1 | 0x7f54c0030d00 | < 100ms | IN|OUT MaxScale> -The resultant output returns data as to the average thread utilisation for the past minutes 5 minutes and 15 minutes. It also gives a table, with a row per thread that shows what DCB that thread is currently processing events for, the events it is processing and how long, to the nearest 100ms has been send processing these events. +The resultant output returns data as to the average thread utilization for the past minutes 5 minutes and 15 minutes. It also gives a table, with a row per thread that shows what DCB that thread is currently processing events for, the events it is processing and how long, to the nearest 100ms has been send processing these events. ## The Event Queue @@ -726,7 +726,7 @@ At the core of MaxScale is an event driven engine that is processing network eve 0x1e22f10 | Processing | IN|OUT | MaxScale> -The output of this command gives the DCB’s that are currenting in the event queue, the events queued for that DCB, and events that are beign processed for that DCB. +The output of this command gives the DCB’s that are currently in the event queue, the events queued for that DCB, and events that are being processed for that DCB. ## The Housekeeper Tasks @@ -770,7 +770,7 @@ This command provides important version information for the module. Each module MaxScale write a number of log files in the log directory within MaxScale home directory. The default option for these is that the grow continually, it is recommended that periodically the log files are rotated. This will close the current log file and open a new one with a new name. The log file names use a sequence number which is incremented each time the logs are rotated. -It is possible to rotate just a single log file, using the flush log command and the name of the log to flush. The names that are recognised by MaxAdmin are error, message, trace or debug. +It is possible to rotate just a single log file, using the flush log command and the name of the log to flush. The names that are recognized by MaxAdmin are error, message, trace or debug. MaxScale> flush log message MaxScale> @@ -819,7 +819,7 @@ Note that this uses the default port of 6603 and confines the connections to loc The way that MaxScale does it’s polling is that each of the polling threads, as defined by the threads parameter in the configuration file, will call epoll_wait to obtain the events that are to be processed. The events are then added to a queue for execution. Any thread can read from this queue, not just the thread that added the event. -Once the thread has done an epoll call with no timeout it will either do an epoll_wait call with a timeout or it will take an event from the queue if there is one. These two new parameters affect this behaviour. +Once the thread has done an epoll call with no timeout it will either do an epoll_wait call with a timeout or it will take an event from the queue if there is one. These two new parameters affect this behavior. The first parameter, which may be set by using the non_blocking_polls option in the configuration file, controls the number of epoll_wait calls that will be issued without a timeout before MaxScale will make a call with a timeout value. The advantage of performing a call without a timeout is that the kernel treats this case as different and will not rescheduled the process in this case. If a timeout is passed then the system call will cause the MaxScale thread to be put back in the scheduling queue and may result in lost CPU time to MaxScale. Setting the value of this parameter too high will cause MaxScale to consume a lot of CPU when there is infrequent work to be done. The default value of this parameter is 3. diff --git a/Documentation/Reference/MaxScale-HA-with-Corosync-Pacemaker.md b/Documentation/Reference/MaxScale-HA-with-Corosync-Pacemaker.md index a4dd35125..7afaf5c0d 100644 --- a/Documentation/Reference/MaxScale-HA-with-Corosync-Pacemaker.md +++ b/Documentation/Reference/MaxScale-HA-with-Corosync-Pacemaker.md @@ -336,7 +336,7 @@ The Corosync / Pacemaker cluster is ready to be configured to manage resources. # MaxScale init script /etc/init.d/maxscale -The MaxScale /etc/init.d./maxscale script allows to start/stop/restart and monitor maxScale process running in the system. +The MaxScale /etc/init.d./maxscale script allows to start/stop/restart and monitor MaxScale process running in the system. Edit it and modify the **MAXSCALE_BASEDIR** to match the installation directory you choose when you installed MaxScale. @@ -400,7 +400,7 @@ For more informations; [http://www.linux-ha.org/wiki/LSB_Resource_Agents](http://www.linux-ha.org/wiki/LSB_Resource_Agents) -After checking maxScale is well managed by the /etc/init.d/script is possible to configure the MAxScale HA via Pacemaker. +After checking MaxScale is well managed by the /etc/init.d/script is possible to configure the MaxScale HA via Pacemaker. # Configure MaxScale for HA with Pacemaker diff --git a/Documentation/Tutorials/Administration-Tutorial.md b/Documentation/Tutorials/Administration-Tutorial.md index d212b2e17..929850eb5 100644 --- a/Documentation/Tutorials/Administration-Tutorial.md +++ b/Documentation/Tutorials/Administration-Tutorial.md @@ -24,7 +24,7 @@ or It is also possible to start MaxScale by executing the maxscale command itself, in this case you must ensure that the environment is correctly setup or command line options are passed. The major elements to consider are the correct setting of the MAXSCALE\_HOME directory and to ensure that LD\_LIBRARY\_PATH. The LD\_LIBRARY\_PATH should include the lib directory that was installed as part of the MaxScale installation, the MAXSCALE\_HOME should point to /usr/local/mariadb-maxscale if a default installation has been created or to the directory this was relocated to. Running the executable $MAXSCALE\_HOME/bin/maxscale will result in MaxScale running as a daemon process, unattached to the terminal in which it was started and using configuration files that it finds in the $MAXSCALE\_HOME directory. -Options may be passed to the MaxScale binary that alter this default behaviour, this options are documented in the table below. +Options may be passed to the MaxScale binary that alter this default behavior, this options are documented in the table below. @@ -137,7 +137,7 @@ To determine what client are currently connected to MaxScale you can use the "li ### Rotating Log Files -MaxScale write log data into four log files with varying degrees of detail. With the exception of the error log, which can not be disabled, these log files may be enabled and disabled via the maxadmin interface or in the configuration file. The default behaviour of MaxScale is to grow the log files indefinitely, the administrator must take action to prevent this. +MaxScale write log data into four log files with varying degrees of detail. With the exception of the error log, which can not be disabled, these log files may be enabled and disabled via the maxadmin interface or in the configuration file. The default behavior of MaxScale is to grow the log files indefinitely, the administrator must take action to prevent this. It is possible to rotate either a single log file or all the log files with a single command. When the logfile is rotated, the current log file is closed and a new log file, with an increased sequence number in its name, is created. Log file rotation is achieved by use of the "flush log" or “flush logs” command in maxadmin. diff --git a/Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md b/Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md index f26bf8bab..d75c6162a 100644 --- a/Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md +++ b/Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md @@ -108,7 +108,7 @@ The username and password, either encrypted or plain text, are stored in the ser user=maxscale passwd=96F99AA1315BDC3604B006F427DD9484 -This completes the definitions required by the service, however listening ports must be associated with a service in order to allow network connections. This is done by creating a series of listener sections. These sections again are named for the convenience of the administrator and should be of type listener with an entry labelled service which contains the name of the service to associate the listener with. Each service may have multiple listeners. +This completes the definitions required by the service, however listening ports must be associated with a service in order to allow network connections. This is done by creating a series of listener sections. These sections again are named for the convenience of the administrator and should be of type listener with an entry labeled service which contains the name of the service to associate the listener with. Each service may have multiple listeners. [Galera Listener] type=listener @@ -123,7 +123,7 @@ A listener must also define the protocol module it will use for the incoming net port=4306 socket=/tmp/DB.Cluster -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 for all database connections in MySQLBackend. @@ -199,7 +199,7 @@ Check the error log in /usr/local/mariadb-maxscale/log to see if any errors are dbserv3 | 192.168.2.3 | 3306 | 0 | Running, Synced, Slave -------------------+-----------------+-------+-------------+-------------------- -A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MaxScale convenience and has no impact on the behaviour of the cluster. +A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MaxScale convenience and has no impact on the behavior of the cluster. % maxadmin -pmariadb list listeners diff --git a/Documentation/Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md b/Documentation/Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md index 5245c65d8..df57e9390 100644 --- a/Documentation/Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md +++ b/Documentation/Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md @@ -101,7 +101,7 @@ The username and password, either encrypted or plain text, are stored in the ser user=maxscale passwd=96F99AA1315BDC3604B006F427DD9484 -This completes the definitions required by the service, however listening ports must be associated with the service in order to allow network connections. This is done by creating a series of listener sections. This section again is named for the convenience of the administrator and should be of type listener with an entry labelled service which contains the name of the service to associate the listener with. A service may have multiple listeners. +This completes the definitions required by the service, however listening ports must be associated with the service in order to allow network connections. This is done by creating a series of listener sections. This section again is named for the convenience of the administrator and should be of type listener with an entry labeled service which contains the name of the service to associate the listener with. A service may have multiple listeners. [Splitter Listener] type=listener @@ -116,7 +116,7 @@ A listener must also define the protocol module it will use for the incoming net 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. @@ -205,7 +205,7 @@ Check the error log in /usr/local/mariadb-maxscale/log to see if any errors are dbserv3 | 192.168.2.3 | 3306 | 0 | Running, Synced, Slave -------------------+-----------------+-------+-------------+-------------------- -A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MaxScale convenience and has no impact on the behaviour of the cluster but does allow the monitor to create these pseudo roles which are utilised by the Read/Write Splitter. +A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MaxScale convenience and has no impact on the behavior of the cluster but does allow the monitor to create these pseudo roles which are utilized by the Read/Write Splitter. % maxadmin -pmariadb list listeners diff --git a/Documentation/Tutorials/MaxScale-Information-Schema.md b/Documentation/Tutorials/MaxScale-Information-Schema.md index d4cdaa2c7..c8ce5c08a 100644 --- a/Documentation/Tutorials/MaxScale-Information-Schema.md +++ b/Documentation/Tutorials/MaxScale-Information-Schema.md @@ -119,7 +119,7 @@ The show variables command can also accept a limited like clause. This like clau ## Show status -The show status command displays a set of status counters, as with show variables the show status command can be passed a simplifed like clause to limit the values returned. +The show status command displays a set of status counters, as with show variables the show status command can be passed a simplified like clause to limit the values returned. mysql> show status; +---------------------------+-------+ diff --git a/Documentation/Tutorials/MySQL-Cluster-Setup.md b/Documentation/Tutorials/MySQL-Cluster-Setup.md index 0cf1209a3..fd6c038ca 100644 --- a/Documentation/Tutorials/MySQL-Cluster-Setup.md +++ b/Documentation/Tutorials/MySQL-Cluster-Setup.md @@ -24,7 +24,7 @@ Last Updated: 1st August 2014 ## Overview -The document covers the MySQL Cluster 7.2.17 setup and MaxScale configuration in order to load balancing the SQL nodes acces. +The document covers the MySQL Cluster 7.2.17 setup and MaxScale configuration in order to load balancing the SQL nodes access. ## MySQL Cluster setup diff --git a/Documentation/Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md b/Documentation/Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md index 8fd8b496a..aac084f7b 100644 --- a/Documentation/Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md +++ b/Documentation/Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md @@ -172,7 +172,7 @@ user=maxscale passwd=96F99AA1315BDC3604B006F427DD9484 -This completes the definitions required by the services, however listening ports must be associated with the services in order to allow network connections. This is done by creating a series of listener sections. These sections again are named for the convenience of the administrator and should be of type listener with an entry labelled service which contains the name of the service to associate the listener with. Each service may have multiple listeners. +This completes the definitions required by the services, however listening ports must be associated with the services in order to allow network connections. This is done by creating a series of listener sections. These sections again are named for the convenience of the administrator and should be of type listener with an entry labeled service which contains the name of the service to associate the listener with. Each service may have multiple listeners. [Write Listener] @@ -210,7 +210,7 @@ protocol=MySQLClient port=4307 -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 for all database connections in MySQLBackend. diff --git a/Documentation/Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md b/Documentation/Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md index 49c151dc2..54e5412be 100644 --- a/Documentation/Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md +++ b/Documentation/Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md @@ -122,7 +122,7 @@ user=maxscale passwd=96F99AA1315BDC3604B006F427DD9484 -This completes the definitions required by the service, however listening ports must be associated with the service in order to allow network connections. This is done by creating a series of listener sections. This section again is named for the convenience of the administrator and should be of type listener with an entry labelled service which contains the name of the service to associate the listener with. A service may have multiple listeners. +This completes the definitions required by the service, however listening ports must be associated with the service in order to allow network connections. This is done by creating a series of listener sections. This section again is named for the convenience of the administrator and should be of type listener with an entry labeled service which contains the name of the service to associate the listener with. A service may have multiple listeners. [Splitter Listener] diff --git a/Documentation/Tutorials/Notification-Service.md b/Documentation/Tutorials/Notification-Service.md index 03edd0378..9cc35c03f 100644 --- a/Documentation/Tutorials/Notification-Service.md +++ b/Documentation/Tutorials/Notification-Service.md @@ -28,7 +28,7 @@ The purpose of Notification Service in MaxScale is for a customer registered for ## MaxScale Setup -MaxScale may collect the installed plugins and send the informations nightly, between 2:00 AM and 4:59 AM. +MaxScale may collect the installed plugins and send the information's nightly, between 2:00 AM and 4:59 AM. It tries to send data and if there is any failure (timeout, server is down, etc), the next retry is in 1800 seconds (30 minutes) @@ -40,7 +40,7 @@ This feature is not enabled by default: MaxScale must be configured in [feedback feedback_url=https://enterprise.mariadb.com/feedback/post feedback_user_info=x-y-z-w -The activation code that will be provided by MariaDB corp upon request by the customer and it shlud be put in feedback_user_info. +The activation code that will be provided by MariaDB corp upon request by the customer and it should be put in feedback_user_info. Example: feedback_user_info=0467009f-b04d-45b1-a77b-b6b2ec9c6cf4 diff --git a/Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md b/Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md index 9d062d861..f07fd13a3 100644 --- a/Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md +++ b/Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md @@ -10,18 +10,18 @@ The most obvious solution to the requirement for a proxy layer within a replicat Using an intermediate master does not however solve all the problems and introduces some due to the way replication is implemented. A slave server reads the binary log data and creates a relay log from that binary log. This then provides a source of SQL statements which are executed within the slave in order to make the same changes to the databases on the slaves as were made on the master. If the log_slave_updates option has been enabled new binary log entries are created for the statements executed from the relay log. This means that the data in the binary log of the intermediate master is not a direct copy of the data that was received from the binary log of the real master. The resultant changes to the database will be the same, provided no updates have been performed on the intermediate master that did not originate on the real master, but the steps to achieve those changes may be different. In particular if group commit functionality is used, to allow multiple transactions to commit in parallel, these may well be different on the intermediate master. This can cause a reduction in the parallelism of the commits and a subsequent reduction in the performance of the slave servers. -This re-execution of the SQL statements also adds latency to the intermediate master solution, since the full process of parsing, optimisation and execution must occur for every statement that is replicated from the master to the slaves must be performed in the intermediate master. This latency introduces lag in the replication chain, with a greater delay being introduced from the time a transaction is committed on the master until the data is available on the slaves. +This re-execution of the SQL statements also adds latency to the intermediate master solution, since the full process of parsing, optimization and execution must occur for every statement that is replicated from the master to the slaves must be performed in the intermediate master. This latency introduces lag in the replication chain, with a greater delay being introduced from the time a transaction is committed on the master until the data is available on the slaves. Use of an intermediate master does improve the process of failover of the master server, since the slaves are only aware of the intermediate master the process of promoting one of the existing slaves to become the new master only involves that slave and the intermediate master. A slave can become the new master as soon as all the changes from the intermediate master have been processed. The intermediate master then needs to be reset to the correct point in the binary log of the new master and replication can continue. -An added complexity that needs to be dealt with is the failure of the intermediate master itself. If this occurs then the same problem as described earlier exists, all slaves must be updated when a new intermediate master is created. If multiple intermediate masters are used there is also a restriction that slaves can not be moved from the failed intermediate master to another intermediate master due to the fact that the binlog on the different intermediate nodes are not gaurenteed to be the same. +An added complexity that needs to be dealt with is the failure of the intermediate master itself. If this occurs then the same problem as described earlier exists, all slaves must be updated when a new intermediate master is created. If multiple intermediate masters are used there is also a restriction that slaves can not be moved from the failed intermediate master to another intermediate master due to the fact that the binlog on the different intermediate nodes are not guaranteed to be the same. ## MaxScale's approach MaxScale takes a much simpler approach to the process of being a replication proxy. It acts as a slave to the real master and as a master to the slaves in the same way as an intermediate master does, however it does not implement any re-execution of the statements within the binary log. MaxScale creates a local cache of the binary logs it receives from the master and it will serve binary log events to the slaves from this cache of the master's binary log. This means that the slaves will always get binary log events that have a one-to-one correlation to those written by the master. Parallelism in the binary log events of the master is maintained in the events that are observed by the slaves. In the MaxScale approach the latency that is introduced is mostly the added network latency associated with adding the extra network hop. There is no appreciable processing performed at the MaxScale level, other than for managing the local cache of the binlog files. -In addition every MaxScale that is acting as a proxy of the master will have exactly the same binlog events as the master itself. This means that a slave can be moved between any of the MaxScale server or to the real master without the need to perform any special processing. The result is much simpler behaviour for failure recovery and the ability to have a very simple, redundant proxy layer with slaves free to both between the proxies. +In addition every MaxScale that is acting as a proxy of the master will have exactly the same binlog events as the master itself. This means that a slave can be moved between any of the MaxScale server or to the real master without the need to perform any special processing. The result is much simpler behavior for failure recovery and the ability to have a very simple, redundant proxy layer with slaves free to both between the proxies. # Configuring MaxScale as a replication proxy Using MaxScale as a replication proxy is much the same as using MaxScale as a proxy between the clients and the database servers. In this case the master server should be considered as the database backend and the slave servers as the clients of MaxScale. diff --git a/Documentation/Tutorials/Simple-Sharding-Tutorial.md b/Documentation/Tutorials/Simple-Sharding-Tutorial.md index 6419386fb..6c16fa9f6 100644 --- a/Documentation/Tutorials/Simple-Sharding-Tutorial.md +++ b/Documentation/Tutorials/Simple-Sharding-Tutorial.md @@ -94,5 +94,5 @@ Upon completion of the configuration process MaxScale is ready to be started . T After starting MaxScale check the error log in /usr/local/mariadb-maxscale/log to see if any errors are detected in the configuration file. Also the maxadmin command may be used to confirm that MaxScale is running and the services, listeners etc have been correctly configured. -MaxScale is now ready to start accepting client connections and routing them. Queries are routed to the right servers based on the database they target and switching between the shards is semaless since MaxScale keeps the session state intact between servers. +MaxScale is now ready to start accepting client connections and routing them. Queries are routed to the right servers based on the database they target and switching between the shards is seamless since MaxScale keeps the session state intact between servers. diff --git a/Documentation/filters/Database-Firewall-Filter.md b/Documentation/filters/Database-Firewall-Filter.md index 98c01b67f..720c16f29 100644 --- a/Documentation/filters/Database-Firewall-Filter.md +++ b/Documentation/filters/Database-Firewall-Filter.md @@ -82,7 +82,7 @@ The first keyword is `users`, which identifies this line as a user definition li The second component is a list of user names and network addresses in the format *`user`*`@`*`0.0.0.0`*. The first part is the user name and the second part is the network address. You can use the `%` character as the wildcard to enable user name matching from any address or network matching for all users. After the list of users and networks the keyword match is expected. -After this either the keyword `any` `all` or `strict_all` is expected. This defined how the rules are matched. If `any` is used when the first rule is matched the query is considered blocked and the rest of the rules are skipped. If instead the `all` keyword is used all rules must match for the query to be blocked. The `strict_all` is the same as `all` but it checks the rules from left to right in the order they were listed. If one of these does not match, the rest of the rules are not checked. This could be usedful in situations where you would for example combine `limit_queries` and `regex` rules. By using `strict_all` you can have the `regex` rule first and the `limit_queries` rule second. This way the rule only matches if the `regex` rule matches enough times for the `limit_queries` rule to match. +After this either the keyword `any` `all` or `strict_all` is expected. This defined how the rules are matched. If `any` is used when the first rule is matched the query is considered blocked and the rest of the rules are skipped. If instead the `all` keyword is used all rules must match for the query to be blocked. The `strict_all` is the same as `all` but it checks the rules from left to right in the order they were listed. If one of these does not match, the rest of the rules are not checked. This could be useful in situations where you would for example combine `limit_queries` and `regex` rules. By using `strict_all` you can have the `regex` rule first and the `limit_queries` rule second. This way the rule only matches if the `regex` rule matches enough times for the `limit_queries` rule to match. After the matching part comes the rules keyword after which a list of rule names is expected. This allows reusing of the rules and enables varying levels of query restriction. diff --git a/Documentation/filters/RabbitMQ-Consumer-Client.md b/Documentation/filters/RabbitMQ-Consumer-Client.md index 9e8bf5edc..324d8623e 100644 --- a/Documentation/filters/RabbitMQ-Consumer-Client.md +++ b/Documentation/filters/RabbitMQ-Consumer-Client.md @@ -22,7 +22,7 @@ The consumer client requires that the `consumer.cnf` configuration file is eithe The source broker, the destination database and the message log file can be configured into the separate `consumer.cnf` file. -| Option | Desctiption | +| Option | Description | |-----------|---------------------------------------------| | hostname | Hostname of the RabbitMQ server | | port | Port of the RabbitMQ server | @@ -34,5 +34,5 @@ The source broker, the destination database and the message log file can be conf | dbport | Port of the SQL server | | dbname | Name of the SQL database to use | | dbuser | Database username | -| dbpasswd | Database passwork | +| dbpasswd | Database password | | logfile | Message log filename | diff --git a/Documentation/filters/RabbitMQ-Filter.md b/Documentation/filters/RabbitMQ-Filter.md index 885b620f6..6f09fb2dd 100644 --- a/Documentation/filters/RabbitMQ-Filter.md +++ b/Documentation/filters/RabbitMQ-Filter.md @@ -5,7 +5,7 @@ This filter is designed to extract queries and transform them into a canonical f ## Configuration -The configuration block for the **mqfilter** filter requires the minimal filter options in it’s section within the MaxScale.cnf file, stored in $MAXSCALE_HOME/etc/MaxScale.cnf. Although the filter will start, it will use the default values which only work with a freshly installed RabbitMQ server and use its default values. This setup is mostly intednded for testing the filter. +The configuration block for the **mqfilter** filter requires the minimal filter options in it’s section within the MaxScale.cnf file, stored in $MAXSCALE_HOME/etc/MaxScale.cnf. Although the filter will start, it will use the default values which only work with a freshly installed RabbitMQ server and use its default values. This setup is mostly intended for testing the filter. The following is an example of a mqfilter configuration in the MaxScale.cnf file used for actual logging of queries to a RabbitMQ broker on a different host. diff --git a/Documentation/filters/Regex-Filter.md b/Documentation/filters/Regex-Filter.md index 76ddb6fad..e0370ed2c 100644 --- a/Documentation/filters/Regex-Filter.md +++ b/Documentation/filters/Regex-Filter.md @@ -56,7 +56,7 @@ user=john ### Example 1 - Replace MySQL 5.1 create table syntax with that for later versions -MySQL 5.1 used the parameter TYPE = to set the storage engine that should be used for a table. In later versions this changed to be ENGINE =. Imagine you have an application that you can not change for some reason, but you wish to migrate to a newer version of MySQL. The regexfilter can be used to transform the create table statments into the form that could be used by MySQL 5.5 +MySQL 5.1 used the parameter TYPE = to set the storage engine that should be used for a table. In later versions this changed to be ENGINE =. Imagine you have an application that you can not change for some reason, but you wish to migrate to a newer version of MySQL. The regexfilter can be used to transform the create table statements into the form that could be used by MySQL 5.5 [CreateTableFilter] diff --git a/Documentation/filters/Tee-Filter.md b/Documentation/filters/Tee-Filter.md index 777b16fa9..65e070ce1 100644 --- a/Documentation/filters/Tee-Filter.md +++ b/Documentation/filters/Tee-Filter.md @@ -58,7 +58,7 @@ user=john Assume an order processing system that has a table called orders. You also have another database server, the datamart server, that requires all inserts into orders to be replicated to it. Deletes and updates are not however required. -Set up a service in MaxScale, called Orders, to communicate with the order processing system with the tee filter applied to it. Also set up a service to talk the datamart server, using the DataMart service. The tee filter woudl have as it’s service entry the DataMart service, by adding a match parameter of "insert into orders" would then result in all requests being sent to the order processing system, and insert statements that include the orders table being additionally sent to the datamart server. +Set up a service in MaxScale, called Orders, to communicate with the order processing system with the tee filter applied to it. Also set up a service to talk the datamart server, using the DataMart service. The tee filter would have as it’s service entry the DataMart service, by adding a match parameter of "insert into orders" would then result in all requests being sent to the order processing system, and insert statements that include the orders table being additionally sent to the datamart server. [Orders] diff --git a/Documentation/filters/Top-N-Filter.md b/Documentation/filters/Top-N-Filter.md index afd960d87..9807e5330 100644 --- a/Documentation/filters/Top-N-Filter.md +++ b/Documentation/filters/Top-N-Filter.md @@ -36,7 +36,7 @@ The number of SQL statements to store and report upon. count=30 -The default vakue for the numebr of statements recorded is 10. +The default value for the number of statements recorded is 10. ### Match @@ -62,7 +62,7 @@ source=127.0.0.1 ### User -The optional user parameter defines a user name that is used to match against the user from which the client connection to MaxScale originates. Only sessions that are connected using this username will result in results being gebnerated. +The optional user parameter defines a user name that is used to match against the user from which the client connection to MaxScale originates. Only sessions that are connected using this username will result in results being generated. user=john @@ -126,11 +126,11 @@ In the router definition add both filters filters=SlowAppServer | ControlAppServer -You will then have two sets of logs files written, one which profiles the top 20 queries of the slow application server and another that gives you the top 20 queries of your control application server. These two sets of files can then be compared to determine what if anythign is different between the two. +You will then have two sets of logs files written, one which profiles the top 20 queries of the slow application server and another that gives you the top 20 queries of your control application server. These two sets of files can then be compared to determine what if anything is different between the two. # Output Report -The following is an example report for a number of fictitious queries executed against the employees exaple database available for MySQL. +The following is an example report for a number of fictitious queries executed against the employees example database available for MySQL. -bash-4.1$ cat /var/logs/top/Employees-top-10.137 diff --git a/README b/README index 8d3c08a13..1ee5b24aa 100644 --- a/README +++ b/README @@ -7,8 +7,8 @@ the various servers within the backend cluster of databases. MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides -a highly scalable and flexibile architecture, with plugin components to -support different protocols and routing decissions. +a highly scalable and flexible architecture, with plugin components to +support different protocols and routing decisions. MaxScale is implemented in C and makes extensive use of the asynchronous I/O capabilities of the Linux operating system. The epoll diff --git a/etc/DESCRIPTION b/etc/DESCRIPTION index bd8df0f59..c86958395 100644 --- a/etc/DESCRIPTION +++ b/etc/DESCRIPTION @@ -5,5 +5,5 @@ the various servers within the backend cluster of databases. MaxScale is designed to provide load balancing and high availability functionality transparently to the applications. In addition it provides -a highly scalable and flexibile architecture, with plugin components to -support different protocols and routing decissions. +a highly scalable and flexible architecture, with plugin components to +support different protocols and routing decisions.