minor docs fixes
This commit is contained in:
parent
b85b4010f2
commit
047ac55a40
@ -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
|
||||
|
@ -22,7 +22,7 @@ module=maxrows
|
||||
[MaxRows Routing Service]
|
||||
type=service
|
||||
...
|
||||
filters=maxrows
|
||||
filters=MaxRows
|
||||
```
|
||||
|
||||
### Filter Parameters
|
||||
|
@ -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 it’s 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]
|
||||
|
@ -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`
|
||||
|
@ -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 it’s 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]
|
||||
|
@ -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]
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
|
Loading…
x
Reference in New Issue
Block a user