Merge remote-tracking branch 'origin/develop' into MXS-105

About/About-MaxScale.md

@@ -13,8 +13,8 @@ A Google Group exists for MaxScale that can be used to discuss ideas, issues and
 Send email to [maxscale@googlegroups.com](mailto:maxscale@googlegroups.com)
 	or use the [forum](http://groups.google.com/forum/#!forum/maxscale) interface
 	
-Bugs can be reported in the MariaDB Corporation bugs database
-	[bug.mariadb.com](http://bugs.mariadb.com)
+Bugs can be reported in the MariaDB Jira
+	[https://mariadb.atlassian.net](https://mariadb.atlassian.net)
 
 ## Installing MaxScale
 Information about installing MaxScale, either from a repository or by building from source code, is included in the guide [Getting Started with MaxScale](/Documentation/Getting-Started/Getting-Started-With-MaxScale.md).

Changelog.md

@@ -2,6 +2,17 @@
 
 These are the changes introduced in the next MaxScale version. This is not the official change log and the latest changelog can always be found in here: [MaxScale 1.1 Release Notes](Release-Notes/MaxScale-1.1-Release-Notes.md)
 
+## MaxScale 1.1.1
+
+* Schemarouter now also allows for an upper limit to session commans.
+* Schemarouter correctly handles SHOW DATABASES responses that span multiple buffers.
+* Schemarouter now allows disabling of the session command history.
+* Readwritesplit now allows disabling of the session command history.
+* Logfiles have been renamed. The log names are now named error.log, messages.log, trace.log and debug.log.
+
+	
+## MaxScale 1.1
+
 **NOTE:** MaxScale default installation directory has changed to `/usr/local/mariadb-maxscale` and the default password for MaxAdmin is now ´mariadb´.
 
 * New modules added

Getting-Started/Configuration-Guide.md

@@ -831,6 +831,8 @@ In above-mentioned case the user-defined variable would only be updated in the m
 
 When a limitation is set, it effectively creates a cap on the session's memory consumption. This might be useful if connection pooling is used and the sessions use large amounts of session commands.
 
+`disable_sescmd_history=true|false` disables the session command history. This way nothing is stored and if a slave server fails and a new one is taken in its stead, the session on that server will be in an inconsistent state compared to the master server. Disabling session command history will allow connection pooling without causing a constant growth in the memory consumption.
+
 An example of Read/Write Split router configuration :
 
 ```

routers/schemarouter/SchemaRouter.md

@@ -42,6 +42,12 @@ GRANT SELECT,USAGE ON shard.* TO 'john'@'%';
 
 This would in effect allow the user 'john' to only see the database 'shard' on this server. Take notice that these grants are matched against MaxScale's hostname instead of the client's hostname. Only user authentication uses the client's hostname and all other grants use MaxScale's hostname.
 
+The schemarouter supports the following router options:
+
+|option				|parameter	|description|
+---------------------------------------------
+|max_sescmd_hitory	|<int>		|Set a limit on the number of session modifying commands a session can execute. This sets an effective cap on the memory consupmtion of the session.|
+|disable_sescmd_history|<boolean>|Disable the session command history. This will prevent growing memory consumption of a long-running session and allows pooled connections to MaxScale to be used. The drawback of this is the fact that if a server goes down, the session state will not be consistent anymore.|
 ## Limitations
 
 The schemarouter router currently has some limitations due to the nature of the sharding implementation and the way the session variables are detected and routed. Here is a list of the current limitations.