Fixed broken links and spelling errors
One link in an older release note was broken and some of the changes made in the documentation had introduced spelling mistakes.
This commit is contained in:
@ -48,7 +48,7 @@ These tutorials are for specific use cases and module combinations.
|
||||
- [RabbitMQ and Tee Filter Data Archiving Tutorial](Tutorials/RabbitMQ-And-Tee-Archiving.md)
|
||||
- [Simple Schema Sharding Tutorial](Tutorials/Simple-Sharding-Tutorial.md)
|
||||
|
||||
Here are tutorials on monitoring and managing MaxScale in cluster envoronments.
|
||||
Here are tutorials on monitoring and managing MaxScale in cluster environments.
|
||||
|
||||
- [Nagios Plugins for MaxScale Tutorial](Tutorials/Nagios-Plugins.md)
|
||||
- [MaxScale HA with Corosync-Pacemaker](Tutorials/MaxScale-HA-with-Corosync-Pacemaker.md)
|
||||
|
@ -31,7 +31,7 @@ MaxScale now supports SSL/TLS encrypted connections to MaxScale.
|
||||
Now you can configure MaxScale monitor module to automatically launch a script when it detects change in the state of a backend server. The script can be any customer script defined by you to take diagnostic or reporting action. With this you can easily customize MaxScale's behavior.
|
||||
|
||||
### Lsyncd configuration guide
|
||||
A new tutorial has been added which helps you keep MaxScale's configuration files in sync across multiple hosts. This allows for easier HA setups with MaxScale and guarantees up-to-date configuration files on all nodes. The tutorial can be found [here](../Reference/MaxScale-HA-with-lsyncd.md).
|
||||
A new tutorial has been added which helps you keep MaxScale's configuration files in sync across multiple hosts. This allows for easier HA setups with MaxScale and guarantees up-to-date configuration files on all nodes. The tutorial can be found [here](../Tutorials/MaxScale-HA-with-lsyncd.md).
|
||||
|
||||
## Bug fixes
|
||||
|
||||
|
@ -145,17 +145,17 @@ master_accept_reads=true
|
||||
|
||||
### `strict_multi_stmt`
|
||||
|
||||
When a client executes a multistatement query, all queries after that will be routed to
|
||||
When a client executes a multi-statement query, all queries after that will be routed to
|
||||
the master to guarantee a consistent session state. This behavior can be controlled with
|
||||
the **`strict_multi_stmt`** router option. This option is enabled by default.
|
||||
|
||||
If set to false, queries are routed normally after a multistatement query. **Warning**, this
|
||||
can cause false data to be read from the slaves if the multistatement query modifies
|
||||
If set to false, queries are routed normally after a multi-statement query. **Warning**, this
|
||||
can cause false data to be read from the slaves if the multi-statement query modifies
|
||||
the session state. Only disable the strict mode if you know that no changes to the session
|
||||
state will be made inside the multistatement queries.
|
||||
state will be made inside the multi-statement queries.
|
||||
|
||||
```
|
||||
# Disable strict multistatement mode
|
||||
# Disable strict multi-statement mode
|
||||
strict_multi_stmt=false
|
||||
```
|
||||
|
||||
|
Reference in New Issue
Block a user