docs typos fixing
This commit is contained in:
Timofey Turenko
Markus Mäkelä
parent
6c583c43dd
commit
b85b4010f2
@ -2,7 +2,7 @@
|
||||
|
||||
## 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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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]
|
||||
@ -27,7 +27,7 @@ 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]
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -74,7 +74,7 @@ same node for writes.
|
||||
|
||||
If the `root_node_as_master` option is disabled for galeramon, the node with the
|
||||
lowest index will always be chosen as the master. If it is enabled, only the
|
||||
node with a a _wsrep_local_index_ value of 0 can be chosed as the master.
|
||||
node with a a _wsrep_local_index_ value of 0 can be chosen as the master.
|
||||
|
||||
### `set_donor_nodes`
|
||||
|
||||
|
||||
@ -87,7 +87,8 @@ detect_stale_slave=true
|
||||
|
||||
### `mysql51_replication`
|
||||
|
||||
Enable support for MySQL 5.1 replication monitoring. This is needed if a MySQL server older than 5.5 is used as a slave in replication.
|
||||
Enable support for MySQL 5.1 replication monitoring. This is needed if a MySQL
|
||||
server older than 5.5 is used as a slave in replication.
|
||||
|
||||
```
|
||||
mysql51_replication=true
|
||||
@ -112,7 +113,7 @@ the master status.
|
||||
By setting the servers into read-only mode, the user can control which
|
||||
server receive the master status. To do this:
|
||||
|
||||
- Enable `@@read_only` on all servers (preferrably through the configuration file)
|
||||
- Enable `@@read_only` on all servers (preferably through the configuration file)
|
||||
- Manually disable `@@read_only` on the server which should be the master
|
||||
|
||||
This functionality is similar to the [Multi-Master Monitor](MM-Monitor.md)
|
||||
@ -146,7 +147,7 @@ This mode in mysqlmon is completely passive in the sense that it does not modify
|
||||
the cluster or any of the servers in it. It only labels the last remaining
|
||||
server in a cluster as the master server.
|
||||
|
||||
Before a server is labeled as a standalone master, the following conditions must
|
||||
Before a server is labelled as a standalone master, the following conditions must
|
||||
have been met:
|
||||
|
||||
- Previous attempts to connect to other servers in the cluster have failed,
|
||||
@ -173,7 +174,7 @@ been set up.
|
||||
### `failcount`
|
||||
|
||||
Number of failures that must occur on all failed servers before a standalone
|
||||
server is labeled as a master. The default value is 5 failures.
|
||||
server is labelled as a master. The default value is 5 failures.
|
||||
|
||||
The monitor will attempt to contact all servers once per monitoring cycle. When
|
||||
`detect_standalone_master` is enabled, all of the failed servers must fail
|
||||
@ -181,7 +182,7 @@ _failcount_ number of connection attempts before the last server is labeled as
|
||||
the master.
|
||||
|
||||
The formula for calculating the actual number of milliseconds before the server
|
||||
is labeled as the master is `monitor_interval * failcount`.
|
||||
is labelled as the master is `monitor_interval * failcount`.
|
||||
|
||||
### `allow_cluster_recovery`
|
||||
|
||||
@ -190,7 +191,7 @@ takes a boolean parameter is enabled by default. This parameter requires that
|
||||
`detect_standalone_master` is set to true. In MaxScale 2.1.0, this parameter was
|
||||
called `failover_recovery`.
|
||||
|
||||
When this parameter is disabled, if the last remaining server is labeled as the
|
||||
When this parameter is disabled, if the last remaining server is labelled as the
|
||||
master, the monitor will set all of the failed servers into maintenance
|
||||
mode. When this option is enabled, the failed servers are allowed to rejoin the
|
||||
cluster.
|
||||
@ -202,7 +203,8 @@ configures the failed servers as new slaves of the current master.
|
||||
|
||||
## Example 1 - Monitor script
|
||||
|
||||
Here is an example shell script which sends an email to an admin when a server goes down.
|
||||
Here is an example shell script which sends an email to an admin@my.org
|
||||
when a server goes down.
|
||||
|
||||
```
|
||||
#!/usr/bin/env bash
|
||||
|
||||
@ -125,7 +125,7 @@ the following format:
|
||||
```
|
||||
|
||||
The avrorouter uses the schema file to identify the columns, their names and
|
||||
what type they are. The Name fiels contains the name of the column and the Type
|
||||
what type they are. The Name fields contains the name of the column and the Type
|
||||
contains the Avro type. Read the [Avro specification](https://avro.apache.org/docs/1.8.1/spec.html)
|
||||
for details on the layout of the schema files.
|
||||
|
||||
|
||||
@ -130,7 +130,7 @@ 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. Add this server into the MariaDB MaxScale configuration and create a service that will connect to this server.
|
||||
```
|
||||
[CassandraDB]
|
||||
type=server
|
||||
|
||||
@ -321,7 +321,7 @@ maxadmin list servers
|
||||
|
||||
Servers.
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
Server | Address | Port | Connections | Status
|
||||
Server | Address | Port | Connections | Status
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
production-1 | 192.168.0.200 | 3306 | 0 | Running
|
||||
archive-1 | 192.168.0.201 | 3000 | 0 | Running
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user