minor docs fixes

This commit is contained in:
Timofey Turenko 2017-04-21 23:29:10 +03:00 committed by Markus Mäkelä
parent b85b4010f2
commit 047ac55a40
10 changed files with 28 additions and 25 deletions

View File

@ -1,4 +1,4 @@
#Database Firewall filter
# Database Firewall filter
## Overview
@ -220,7 +220,7 @@ 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
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 as matched and the rest of the rules are
skipped. If instead the `all` keyword is used all rules must match for the query

View File

@ -22,7 +22,7 @@ module=maxrows
[MaxRows Routing Service]
type=service
...
filters=maxrows
filters=MaxRows
```
### Filter Parameters

View File

@ -6,7 +6,7 @@ The **namedserverfilter** is a filter module for MariaDB MaxScale which is able
## Configuration
The configuration block for the Named Server filter requires the minimal filter options in its section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
The configuration block for the Named Server filter requires the minimal filter options in its section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
```
[NamedServerFilter]

View File

@ -6,7 +6,7 @@ The Query Log All (QLA) filter is a filter module for MariaDB MaxScale that is a
## Configuration
The configuration block for the QLA filter requires the minimal filter options in it's section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
The configuration block for the QLA filter requires the minimal filter options in its section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
```
[MyLogFilter]
type=filter
@ -31,7 +31,7 @@ The QLA filter accepts the following options.
case | Use case-sensitive matching
extended | Use extended regular expression syntax (ERE)
To use multiple filter options, list them in a comma-separated list. If no file settings are given, default will be used. Multiple file settings can be enabled simultaneously.
To use multiple filter options, list them in a comma-separated list. If no options are given, default will be used. Multiple options can be enabled simultaneously.
```
options=case,extended
@ -53,7 +53,7 @@ The basename of the output file created for each session. A session index is add
filebase=/tmp/SqlQueryLog
```
The filebase may also be set as the filter, the mechanism to set the filebase via the filter option is superseded by the parameter. If both are set the parameter setting will be used and the filter option ignored.
The filebase may also be set as the filter option, the mechanism to set the filebase via the filter option is superseded by the parameter. If both are set the parameter setting will be used and the filter option ignored.
### `match`
@ -99,8 +99,7 @@ user=john
### `log_type`
The type of log file to use. Parameter value is a comma separated list of the
following values. The default value is _session_.
The type of log file to use. The default value is _session_.
|Value | Description |
|--------|--------------------------------|
@ -108,7 +107,7 @@ following values. The default value is _session_.
|unified |Use one file for all sessions |
```
log_type=session, unified
log_type=session
```
### `log_data`

View File

@ -10,7 +10,7 @@ Please note that the PCRE2 library uses a different syntax to refer to capture g
## Configuration
The configuration block for the Regex filter requires the minimal filter options in its section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
The configuration block for the Regex filter requires the minimal filter options in its section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
```
[MyRegexFilter]

View File

@ -104,7 +104,7 @@ user=john
You have an order system and believe the updates of the PRODUCTS table is causing some performance issues for the rest of your application. You would like to know which of the many updates in your application is causing the issue.
Add a filter with the following definition;
Add a filter with the following definition:
```
[ProductsUpdateTop20]
@ -120,9 +120,9 @@ Note the exclude entry, this is to prevent updates to the PRODUCTS_STOCK table f
### Example 2 - One Application Server is Slow
One of your applications servers is slower than the rest, you believe it is related to database access but you not not sure what is taking the time.
One of your applications servers is slower than the rest, you believe it is related to database access but you are not sure what is taking the time.
Add a filter with the following definition;
Add a filter with the following definition:
```
[SlowAppServer]

View File

@ -107,7 +107,7 @@ set_donor_nodes=true
If the `use_priority` option is set and a server is configured with the
`priority=<int>` parameter, galeramon will use that as the basis on which the
master node is chosen. This requires the `disable_master_role_setting` to be
undefined or disabled. The server with the lowest positive value in _priority_
undefined or disabled. The server with the lowest positive value of _priority_
will be chosen as the master node when a replacement Galera node is promoted to
a master server inside MaxScale.
@ -115,7 +115,7 @@ Nodes with a non-positive value (_priority_ <= 0) will never be chosen as the ma
you to mark some servers as permanent slaves by assigning a non-positive value
into _priority_.
Here is an example with two servers.
Here is an example.
```
[node-1]
@ -147,9 +147,9 @@ In this example `node-1` is always used as the master if available. If `node-1`
is not available, then the next node with the highest priority rank is used. In
this case it would be `node-3`. If both `node-1` and `node-3` were down, then
`node-2` would be used. Because `node-4` has a value of 0 in _priority_, it will
never be the master. Nodes without priority are considered as having the lowest
priority rank and will be used only if all nodes with priority ranks are not
available.
never be the master. Nodes without _priority_ parameter are considered as
having the lowest priority rank and will be used only if all nodes
with _priority_ parameter are not available.
With priority ranks you can control the order in which MaxScale chooses the
master node. This will allow for a controlled failure and replacement of nodes.

View File

@ -35,9 +35,9 @@ These are optional parameters specific to the MySQL Monitor.
### `detect_replication_lag`
A truth value which controls if replication lag between the master and the
A boolean value which controls if replication lag between the master and the
slaves is monitored. This allows the routers to route read queries to only
slaves that are up to date. Default value for this parameter is false.
slaves that are up to date. Default value for this parameter is _false_.
To detect the replication lag, MaxScale uses the _maxscale_schema.replication_heartbeat_
table. This table is created on the master server and it is updated at every heartbeat

View File

@ -130,13 +130,16 @@ servers=dbbubble1,dbbubble2,dbbubble3,dbbubble4,dbbubble5
user=maxscale
passwd=6628C50E07CCE1F0392EDEEB9D1203F3
```
The table you wish to store in Cassandra in called HighScore and will contain the same columns in both the MariaDB table and the Cassandra table. The first step is to install a MariaDB instance with the Cassandra storage engine to act as a bridge server between the relational database and Cassandra. In this bridge server add a table definition for the HighScore table with the engine type set to Cassandra. Add this server into the MariaDB MaxScale configuration and create a service that will connect to this server.
The table you wish to store in Cassandra in called HighScore and will contain the same columns in both the MariaDB table and the Cassandra table. The first step is to install a MariaDB instance with the Cassandra storage engine to act as a bridge server between the relational database and Cassandra. In this bridge server add a table definition for the HighScore table with the engine type set to Cassandra.
See [Cassandra Storage Engine Overview]( https://mariadb.com/kb/en/mariadb/cassandra-storage-engine-overview/) for details.
Add this server into the MariaDB MaxScale configuration and create a service that will connect to this server.
```
[CassandraDB]
type=server
address=192.168.4.28
port=3306
protocol=MySQLBackend
[Cassandra]
type=service
router=readconnrouter

View File

@ -28,7 +28,8 @@ set up replication between the two. The only thing we need to do is to create th
users we will use for monitoring and authentication.
The process of creating monitoring and authentication users for MariaDB MaxScale is described
in the Creating Database Users section of the [MariaDB MaxScale Tutorial](MaxScale-Tutorial.md).
in the Creating Database Users section of the
[MariaDB MaxScale Tutorial](MaxScale-Tutorial.md#creating-database-users).
## Setting up RabbitMQ server
@ -301,7 +302,7 @@ router=cli
type=listener
service=MaxAdmin Service
protocol=maxscaled
port=6603
socket=default
```
## Testing the setup
@ -317,7 +318,7 @@ sudo systemctl start maxscale
We can see the state of the two servers with MaxAdmin:
```
maxadmin list servers
sudo maxadmin list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------