diff --git a/Documentation/Filters/Database-Firewall-Filter.md b/Documentation/Filters/Database-Firewall-Filter.md index 76dd81135..67e7ba548 100644 --- a/Documentation/Filters/Database-Firewall-Filter.md +++ b/Documentation/Filters/Database-Firewall-Filter.md @@ -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 diff --git a/Documentation/Filters/Maxrows.md b/Documentation/Filters/Maxrows.md index 5f894b8bc..60e7203cf 100644 --- a/Documentation/Filters/Maxrows.md +++ b/Documentation/Filters/Maxrows.md @@ -22,7 +22,7 @@ module=maxrows [MaxRows Routing Service] type=service ... -filters=maxrows +filters=MaxRows ``` ### Filter Parameters diff --git a/Documentation/Filters/Named-Server-Filter.md b/Documentation/Filters/Named-Server-Filter.md index a117c375f..1e58893d0 100644 --- a/Documentation/Filters/Named-Server-Filter.md +++ b/Documentation/Filters/Named-Server-Filter.md @@ -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] diff --git a/Documentation/Filters/Query-Log-All-Filter.md b/Documentation/Filters/Query-Log-All-Filter.md index a66362fdb..39ebdf401 100644 --- a/Documentation/Filters/Query-Log-All-Filter.md +++ b/Documentation/Filters/Query-Log-All-Filter.md @@ -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` diff --git a/Documentation/Filters/Regex-Filter.md b/Documentation/Filters/Regex-Filter.md index b2e121b1b..c4cdf603c 100644 --- a/Documentation/Filters/Regex-Filter.md +++ b/Documentation/Filters/Regex-Filter.md @@ -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] diff --git a/Documentation/Filters/Top-N-Filter.md b/Documentation/Filters/Top-N-Filter.md index d8024304b..1e2103338 100644 --- a/Documentation/Filters/Top-N-Filter.md +++ b/Documentation/Filters/Top-N-Filter.md @@ -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] diff --git a/Documentation/Monitors/Galera-Monitor.md b/Documentation/Monitors/Galera-Monitor.md index 8e1bca8ea..a04d86aea 100644 --- a/Documentation/Monitors/Galera-Monitor.md +++ b/Documentation/Monitors/Galera-Monitor.md @@ -107,7 +107,7 @@ set_donor_nodes=true If the `use_priority` option is set and a server is configured with the `priority=` 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. diff --git a/Documentation/Monitors/MySQL-Monitor.md b/Documentation/Monitors/MySQL-Monitor.md index 1dd06d589..e49459e59 100644 --- a/Documentation/Monitors/MySQL-Monitor.md +++ b/Documentation/Monitors/MySQL-Monitor.md @@ -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 diff --git a/Documentation/Tutorials/Filter-Tutorial.md b/Documentation/Tutorials/Filter-Tutorial.md index 218f2a22a..e6af4a93b 100644 --- a/Documentation/Tutorials/Filter-Tutorial.md +++ b/Documentation/Tutorials/Filter-Tutorial.md @@ -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 diff --git a/Documentation/Tutorials/RabbitMQ-And-Tee-Archiving.md b/Documentation/Tutorials/RabbitMQ-And-Tee-Archiving.md index 259744f6d..a51b1856b 100644 --- a/Documentation/Tutorials/RabbitMQ-And-Tee-Archiving.md +++ b/Documentation/Tutorials/RabbitMQ-And-Tee-Archiving.md @@ -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. -------------------+-----------------+-------+-------------+--------------------