Fixed typos in documentation.

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.
 
 <table>
   <tr>
@@ -137,7 +137,7 @@ To determine what client are currently connected to MaxScale you can use the "li
 <a name="rotating"></a> 
 ### 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.
 

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
 

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
 

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;
     +---------------------------+-------+

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
 

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.
 

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]
 

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

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.

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.