hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch '2.1' into develop

Browse Source
This commit is contained in:
Markus Mäkelä
2017-05-17 13:48:31 +03:00
parent 3b8bda289e 4050cd20d8
commit 322983a5f4
36 changed files with 645 additions and 245 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
Documentation/Filters/Database-Firewall-Filter.md
View File

@ -1,8 +1,8 @@
#Database Firewall filter
# Database Firewall filter
## Overview
The database firewall filter is used to block queries that match a set of
The Database Firewall filter is used to block queries that match a set of
rules. It can be used to prevent harmful queries from reaching the backend
database instances or to limit access to the database based on a more flexible
set of rules compared to the traditional GRANT-based privilege system. Currently
@ -10,9 +10,9 @@ the filter does not support multi-statements.
## Configuration
The database firewall filter only requires minimal configuration in the
maxscale.cnf file. The actual rules of the database firewall filter are located
in a separate text file. The following is an example of a database firewall
The Database Firewall filter only requires minimal configuration in the
maxscale.cnf file. The actual rules of the Database Firewall filter are located
in a separate text file. The following is an example of a Database Firewall
filter configuration in maxscale.cnf.
```
@ -32,7 +32,7 @@ filters=DatabaseFirewall
### Filter Parameters
The database firewall filter has one mandatory parameter, `rules`.
The Database Firewall filter has one mandatory parameter, `rules`.
#### `rules`
@ -128,7 +128,7 @@ parameter (_allow_, _block_ or _ignore_).
### Mandatory rule parameters
The database firewall filter's rules expect a single mandatory parameter for a
The Database Firewall filter's rules expect a single mandatory parameter for a
rule. You can define multiple rules to cover situations where you would like to
apply multiple mandatory rules to a query.
@ -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
@ -260,7 +260,7 @@ Shows the current statistics of the rules.
To prevent the excessive use of a database we want to set a limit on the rate of
queries. We only want to apply this limit to certain queries that cause unwanted
behavior. To achieve this we can use a regular expression.
behaviour. To achieve this we can use a regular expression.
First we define the limit on the rate of queries. The first parameter for the
rule sets the number of allowed queries to 10 queries and the second parameter

9
Documentation/Filters/Masking.md
View File

@ -35,6 +35,8 @@ the _ssn_ would be masked, as in
...
```
## Security
Note that he masking filter alone is *not* sufficient for preventing
access to a particular column. As the masking filter works on the column
name alone a query like
@ -49,8 +51,11 @@ a sufficient number of times with different _ssn_ values, will, eventually,
reveal the social security number of all persons in the database.
For a secure solution, the masking filter *must* be combined with the
firewall filter to prevent the use of functions and the use of particular
columns in where-clauses.
firewall filter to prevent the use of functions using which the masking
can be bypassed.
In a future release, the combined use of the masking filter and the
database firewall filter will be simplified.
## Limitations

14
Documentation/Filters/Maxrows.md
View File

@ -3,7 +3,7 @@
This filter was introduced in MariaDB MaxScale 2.1.
## Overview
The maxrows filter is capable of restricting the amount of rows that a SELECT,
The Maxrows filter is capable of restricting the amount of rows that a SELECT,
a prepared statement or stored procedure could return to the client application.
If a resultset from a backend server has more rows than the configured limit
@ -12,7 +12,7 @@ or the resultset size exceeds the configured size,
## Configuration
The maxrows filter is easy to configure and to add to any existing service.
The Maxrows filter is easy to configure and to add to any existing service.
```
[MaxRows]
@ -22,12 +22,12 @@ module=maxrows
[MaxRows Routing Service]
type=service
...
filters=maxrows
filters=MaxRows
```
### Filter Parameters
The maxrows filter has no mandatory parameters.
The Maxrows filter has no mandatory parameters.
Optional parameters are:
#### `max_resultset_rows`
@ -81,7 +81,7 @@ ERROR 1415 (0A000): Row limit/size exceeded for query: select * from test.t4
#### `debug`
An integer value, using which the level of debug logging made by the maxrows
An integer value, using which the level of debug logging made by the Maxrows
filter can be controlled. The value is actually a bitfield with different bits
denoting different logging.
@ -97,8 +97,8 @@ debug=2
## Example Configuration
Here is an example of filter configuration where the max number of returned
rows is 10000 and max allowed resultset size is 256KB
Here is an example of filter configuration where the maximum number of returned
rows is 10000 and maximum allowed resultset size is 256KB
```
[MaxRows]

11
Documentation/Filters/Query-Log-All-Filter.md
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`

6
Documentation/Filters/Regex-Filter.md
View File

@ -2,7 +2,7 @@
## Overview
The regex filter is a filter module for MariaDB MaxScale that is able to rewrite query content using regular expression matches and text substitution. It uses the PCRE2 syntax which differs from the POSIX regular expressions used in MariaDB MaxScale versions prior to 1.3.0.
The Regex filter is a filter module for MariaDB MaxScale that is able to rewrite query content using regular expression matches and text substitution. It uses the PCRE2 syntax which differs from the POSIX regular expressions used in MariaDB MaxScale versions prior to 1.3.0.
For all details about the PCRE2 syntax, please read the [PCRE2 syntax documentation](http://www.pcre.org/current/doc/html/pcre2syntax.html).
@ -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]
@ -30,7 +30,7 @@ filters=MyRegexfilter
## Filter Options
The regex filter accepts the options ignorecase or case. These define if the pattern text should take the case of the string it is matching against into consideration or not.
The Regex filter accepts the options ignorecase or case. These define if the pattern text should take the case of the string it is matching against into consideration or not.
## Filter Parameters

6
Documentation/Filters/Top-N-Filter.md
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]