Merge branch '2.1' into develop
This commit is contained in:
Markus Mäkelä
commit
92b6caa334
@ -24,7 +24,7 @@ connection data. The return value of this function is stored in the
|
||||
`destroy` entry point and the value returned by `create` will be given as the
|
||||
first parameter.
|
||||
|
||||
# MySQL Authentication Moduels
|
||||
# MySQL Authentication Modules
|
||||
|
||||
The MySQL protocol authentication starts when the server sends the
|
||||
[handshake packet](https://dev.mysql.com/doc/internals/en/connection-phase-packets.html#packet-Protocol::Handshake)
|
||||
|
||||
@ -82,7 +82,7 @@ For more details, please refer to [MariaDB MaxScale 1.3 Release Notes](Release-N
|
||||
* Firewall filter
|
||||
* Multi-Master monitor
|
||||
* RabbitMQ logging filter
|
||||
* Schema Sharding router
|
||||
* Schema Sharding router
|
||||
* Added option to use high precision timestamps in logging.
|
||||
* Readwritesplit router now returns the master server's response.
|
||||
* New readwritesplit router option added. It is now possible to control the amount of memory readwritesplit sessions will consume by limiting the amount of session modifying statements they can execute.
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -41,8 +41,8 @@ These tutorials are for specific use cases and module combinations.
|
||||
- [Galera Cluster Connection Routing Tutorial](Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md)
|
||||
- [Galera Gluster Read Write Splitting Tutorial](Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md)
|
||||
- [MySQL Cluster Setup](Tutorials/MySQL-Cluster-Setup.md)
|
||||
- [MySQL Replication Connection Routing Tutorial](Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md)
|
||||
- [MySQL Replication Read Write Splitting Tutorial](Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md)
|
||||
- [MariaDB Replication Connection Routing Tutorial](Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md)
|
||||
- [MariaDB Replication Read Write Splitting Tutorial](Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md)
|
||||
- [MariaDB MaxScale Information Schema Tutorial](Tutorials/MaxScale-Information-Schema.md)
|
||||
- [Notification Service](Tutorials/Notification-Service.md)
|
||||
- [RabbitMQ and Tee Filter Data Archiving Tutorial](Tutorials/RabbitMQ-And-Tee-Archiving.md)
|
||||
|
||||
@ -134,13 +134,29 @@ apply multiple mandatory rules to a query.
|
||||
|
||||
#### `wildcard`
|
||||
|
||||
This rule blocks all queries that use the wildcard character *.
|
||||
This rule blocks all queries that use the wildcard character `*`.
|
||||
|
||||
##### Example
|
||||
|
||||
Use of the wildcard is not allowed:
|
||||
|
||||
```
|
||||
rule examplerule deny wildcard
|
||||
```
|
||||
|
||||
#### `columns`
|
||||
|
||||
This rule expects a list of values after the `columns` keyword. These values are
|
||||
interpreted as column names and if a query targets any of these, it is matched.
|
||||
|
||||
##### Example
|
||||
|
||||
Deny name and salary columns:
|
||||
|
||||
```
|
||||
rule examplerule deny columns name salary
|
||||
```
|
||||
|
||||
#### `function`
|
||||
|
||||
This rule expects a list of values after the `function` keyword. These values
|
||||
@ -149,6 +165,14 @@ matched. The symbolic comparison operators (`<`, `>`, `>=` etc.) are also
|
||||
considered functions whereas the text versions (`NOT`, `IS`, `IS NOT` etc.) are
|
||||
not considered functions.
|
||||
|
||||
##### Example
|
||||
|
||||
Deny SUM and COUNT functions:
|
||||
|
||||
```
|
||||
rule examplerule deny function sum count
|
||||
```
|
||||
|
||||
#### `regex`
|
||||
|
||||
This rule blocks all queries matching a regex enclosed in single or double
|
||||
@ -156,15 +180,31 @@ quotes. The regex string expects a PCRE2 syntax regular expression. For more
|
||||
information about the PCRE2 syntax, read the [PCRE2
|
||||
documentation](http://www.pcre.org/current/doc/html/pcre2syntax.html).
|
||||
|
||||
##### Example
|
||||
|
||||
Block selects to accounts:
|
||||
|
||||
```
|
||||
rule examplerule deny regex '.*select.*from.*accounts.*'
|
||||
```
|
||||
|
||||
#### `limit_queries`
|
||||
|
||||
The limit_queries rule expects three parameters. The first parameter is the
|
||||
number of allowed queries during the time period. The second is the time period
|
||||
in seconds and the third is the amount of time for which the rule is considered
|
||||
active and blocking.
|
||||
in seconds and the third is the amount of time in seconds for which the rule is
|
||||
considered active and blocking.
|
||||
|
||||
**WARNING:** Using `limit_queries` in `action=allow` is not supported.
|
||||
|
||||
##### Example
|
||||
|
||||
Over 50 queries within a window of 5 seconds will block for 100 seconds:
|
||||
|
||||
```
|
||||
rule examplerule deny limit_queries 50 5 100
|
||||
```
|
||||
|
||||
#### `no_where_clause`
|
||||
|
||||
This rule inspects the query and blocks it if it has no WHERE clause. For
|
||||
@ -172,6 +212,14 @@ example, this would disallow a `DELETE FROM ...` query without a `WHERE`
|
||||
clause. This does not prevent wrongful usage of the `WHERE` clause e.g. `DELETE
|
||||
FROM ... WHERE 1=1`.
|
||||
|
||||
##### Example
|
||||
|
||||
Queries must have a where clause:
|
||||
|
||||
```
|
||||
rule examplerule deny no_where_clause
|
||||
```
|
||||
|
||||
### Optional rule parameters
|
||||
|
||||
Each mandatory rule accepts one or more optional parameters. These are to be
|
||||
|
||||
@ -49,7 +49,7 @@ The entry points for the Lua script expect the following signatures:
|
||||
- The `closeSession` function in the Lua scripts will be called.
|
||||
|
||||
- `(nil | bool | string) routeQuery(string)` - query is being routed
|
||||
|
||||
|
||||
- The Luafilter calls the `routeQuery` functions of both the session and the
|
||||
global script. The query is passed as a string parameter to the
|
||||
routeQuery Lua function and the return values of the session specific
|
||||
|
||||
@ -67,7 +67,7 @@ configured into the separate `consumer.cnf` file.
|
||||
| user | Username for the RabbitMQ server |
|
||||
| passwd | Password for the RabbitMQ server |
|
||||
| queue | Queue to consume from |
|
||||
| dbserver | Hostname of the SQL server |
|
||||
| dbserver | Hostname of the SQL server |
|
||||
| dbport | Port of the SQL server |
|
||||
| dbname | Name of the SQL database to use |
|
||||
| dbuser | Database username |
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -210,6 +210,6 @@ Average statement execution time 1.488 seconds
|
||||
|
||||
Total connection time 46.500 seconds
|
||||
|
||||
-bash-4.1$
|
||||
-bash-4.1$
|
||||
|
||||
```
|
||||
|
||||
@ -1231,7 +1231,7 @@ MariaDB MaxScale to connect to MariaDB MaxScale.
|
||||
##### `MySQLBackend`
|
||||
|
||||
The MySQLBackend protocol module is the implementation of the protocol that
|
||||
MariaDB MaxScale uses to connect to the backend MySQL, MariaDB and Percona
|
||||
MariaDB MaxScale uses to connect to the backend MariaDB, MySQL and Percona
|
||||
Server databases. This implementation is tailored for the MariaDB MaxScale to
|
||||
MySQL Database traffic and is not a general purpose implementation of the MySQL
|
||||
protocol.
|
||||
@ -1449,12 +1449,12 @@ Monitors can not be completely removed from the running MariaDB MaxScale.
|
||||
|
||||
## Authentication
|
||||
|
||||
MySQL uses username, passwords and the client host in order to authenticate a
|
||||
MariaDB uses username, passwords and the client host in order to authenticate a
|
||||
user, so a typical user would be defined as user X at host Y and would be given
|
||||
a password to connect. MariaDB MaxScale uses exactly the same rules as MySQL
|
||||
a password to connect. MariaDB MaxScale uses exactly the same rules as MariaDB
|
||||
when users connect to the MariaDB MaxScale instance, i.e. it will check the
|
||||
address from which the client is connecting and treat this in exactly the same
|
||||
way that MySQL would. MariaDB MaxScale will pull the authentication data from
|
||||
way that MariaDB would. MariaDB MaxScale will pull the authentication data from
|
||||
one of the backend servers and use this to match the incoming connections, the
|
||||
assumption being that all the backend servers for a particular service will
|
||||
share the same set of user credentials.
|
||||
@ -1493,10 +1493,10 @@ backends as it would also use the password *pass2* for these connections.
|
||||
|
||||
### Wildcard Hosts
|
||||
|
||||
Hostname mapping in MariaDB MaxScale works in exactly the same way as for MySQL,
|
||||
Hostname mapping in MariaDB MaxScale works in exactly the same way as for MariaDB,
|
||||
if the wildcard is used for the host then any host other than the localhost
|
||||
(127.0.0.1) will match. It is important to consider that the localhost check
|
||||
will be performed at the MariaDB MaxScale level and at the MySQL server level.
|
||||
will be performed at the MariaDB MaxScale level and at the MariaDB server level.
|
||||
|
||||
If MariaDB MaxScale and the databases are on separate hosts there are two
|
||||
important changes in behavior to consider:
|
||||
|
||||
@ -92,20 +92,20 @@ what it is you want to achieve with your MariaDB MaxScale and what environment
|
||||
it will run in. The later is probably the easiest starting point for choosing
|
||||
which configuration route you wish to take.
|
||||
There are two distinct database environments which the first GA release
|
||||
of MariaDB MaxScale supports; MySQL Master/Slave Replication clusters and Galera Cluster.
|
||||
of MariaDB MaxScale supports; MariaDB Master/Slave Replication clusters and Galera Cluster.
|
||||
|
||||
For more details, refer to the [Configuration Guide](Configuration-Guide.md).
|
||||
|
||||
### Master/Slave Replication Clusters
|
||||
|
||||
There are two major configuration options available to use MariaDB MaxScale
|
||||
with a MySQL Replication cluster; connection routing with separate read and
|
||||
with a MariaDB Replication cluster; connection routing with separate read and
|
||||
write connections, or read/write splitting with a single connection.
|
||||
A separate tutorial is available for each of these configurations that
|
||||
describes how to build the configuration file for MariaDB MaxScale that
|
||||
will work with your environment.
|
||||
|
||||
Using a MySQL Master/Slave Replication cluster will provide one node server
|
||||
Using a MariaDB Master/Slave Replication cluster will provide one node server
|
||||
within the cluster that is the master server and the remainder of the servers
|
||||
will be slaves. The slaves are read replicas of the master.
|
||||
In a replication cluster like this all write operations must be performed
|
||||
|
||||
@ -40,7 +40,7 @@ disable_master_failback=true
|
||||
|
||||
### `available_when_donor`
|
||||
|
||||
This option only has an effect if there is a single Galera node being backed up an XtraBackup instance. This causes the initial node to go into Donor state which would normally prevent if from being marked as a valid server inside MaxScale. If this option is enabled, a single node in Donor state where the method is XtraBackup will be kept in Synced state.
|
||||
This option only has an effect if there is a single Galera node being backed up an XtraBackup instance. This causes the initial node to go into Donor state which would normally prevent if from being marked as a valid server inside MaxScale. If this option is enabled, a single node in Donor state where the method is XtraBackup will be kept in Synced state.
|
||||
|
||||
```
|
||||
available_when_donor=true
|
||||
@ -93,7 +93,7 @@ Example of variable being set in all slave nodes, assuming three nodes:
|
||||
SET GLOBAL wsrep_sst_donor = "galera001,galera000"
|
||||
```
|
||||
|
||||
**Note**:
|
||||
**Note**:
|
||||
in order to set the global variable _wsrep_sst_donor_, proper privileges are
|
||||
required for the monitor user that connects to cluster nodes.
|
||||
This option is disabled by default and was introduced in MaxScale 2.1.0.
|
||||
@ -147,7 +147,7 @@ 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_ parameter are considered as
|
||||
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.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
CDC is a new protocol that allows compatible clients to authenticate and
|
||||
register for Change Data Capture events. The new protocol must be use in
|
||||
conjunction with AVRO router which currently converts MySQL binlog events into
|
||||
conjunction with AVRO router which currently converts MariaDB binlog events into
|
||||
AVRO records. Change Data Capture protocol is used by clients in order to
|
||||
interact with stored AVRO file and also allows registered clients to be notified
|
||||
with the new events coming from MariaDB 10.0/10.1 database.
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
Change Data Capture (CDC) is a new MaxScale protocol that allows compatible
|
||||
clients to authenticate and register for Change Data Capture events. The new
|
||||
protocol must be use in conjunction with AVRO router which currently converts
|
||||
MySQL binlog events into AVRO records. Clients connect to CDC listener and
|
||||
MariaDB binlog events into AVRO records. Clients connect to CDC listener and
|
||||
authenticate using credentials provided in a format described in the [CDC Protocol documentation](CDC.md).
|
||||
|
||||
**Note**: If no users are found in that file or if it doesn't exist, the only
|
||||
|
||||
@ -37,7 +37,7 @@ All hints must start with the `maxscale` tag.
|
||||
|
||||
```
|
||||
-- maxscale <hint body>
|
||||
```
|
||||
```
|
||||
|
||||
The hints have two types, ones that define a server type and others that contain
|
||||
name-value pairs.
|
||||
|
||||
@ -558,7 +558,7 @@ RWSplit | readwritesplit | 1 | 1 | server
|
||||
SchemaRouter | schemarouter | 1 | 1 | server1, server2, server3, server4
|
||||
RWSplit-Hint | readwritesplit | 1 | 1 | server1, server2, server3, server4
|
||||
ReadConn | readconnroute | 1 | 1 | server1
|
||||
CLI | cli | 2 | 2 |
|
||||
CLI | cli | 2 | 2 |
|
||||
--------------------------+-------------------+--------+----------------+-------------------
|
||||
MaxScale>
|
||||
```
|
||||
@ -619,7 +619,7 @@ MaxScale> show service RWSplit
|
||||
[127.0.0.1]:3003 Protocol: MySQLBackend Name: server4
|
||||
Total connections: 1
|
||||
Currently connected: 1
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
This allows the set of backend servers defined by the service to be seen along
|
||||
@ -635,8 +635,8 @@ command can be used to examine the user data held by MariaDB MaxScale.
|
||||
|
||||
```
|
||||
MaxScale> show dbusers RWSplit
|
||||
User names: @localhost @localhost.localdomain 14567USER@localhost monuser@localhost monuser@% 14609USER@localhost maxuser@localhost maxuser@% 14651USER@localhost maxtest@localhost maxtest@% 14693USER@localhost skysql@localhost skysql@% 14735USER@localhost cliuser@localhost cliuser@% repuser@localhost repuser@%
|
||||
MaxScale>
|
||||
User names: @localhost @localhost.localdomain 14567USER@localhost monuser@localhost monuser@% 14609USER@localhost maxuser@localhost maxuser@% 14651USER@localhost maxtest@localhost maxtest@% 14693USER@localhost skysql@localhost skysql@% 14735USER@localhost cliuser@localhost cliuser@% repuser@localhost repuser@%
|
||||
MaxScale>
|
||||
|
||||
```
|
||||
|
||||
@ -664,7 +664,7 @@ accepted.
|
||||
|
||||
```
|
||||
MaxScale> shutdown service RWSplit
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
## Restart A Stopped Service
|
||||
@ -678,7 +678,7 @@ MaxScale>
|
||||
|
||||
# Working With Servers
|
||||
|
||||
The server represents each of the instances of MySQL or MariaDB that a service
|
||||
The server represents each of the instances of MariaDB or MySQL that a service
|
||||
may use.
|
||||
|
||||
## What Servers Are Configured?
|
||||
@ -690,14 +690,14 @@ configured within MariaDB MaxScale.
|
||||
MaxScale> list servers
|
||||
Servers.
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
Server | Address | Port | Connections | Status
|
||||
Server | Address | Port | Connections | Status
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
server1 | 127.0.0.1 | 3000 | 0 | Master, Running
|
||||
server2 | 127.0.0.1 | 3001 | 0 | Slave, Running
|
||||
server3 | 127.0.0.1 | 3002 | 0 | Slave, Running
|
||||
server4 | 127.0.0.1 | 3003 | 0 | Slave, Running
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
## Server Details
|
||||
@ -715,12 +715,12 @@ Server 0x6501d0 (server2)
|
||||
Server Version: 10.1.22-MariaDB
|
||||
Node Id: 3001
|
||||
Master Id: 3000
|
||||
Slave Ids:
|
||||
Slave Ids:
|
||||
Repl Depth: 1
|
||||
Number of connections: 0
|
||||
Current no. of conns: 0
|
||||
Current no. of operations: 0
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
If the server has a non-zero value set for the server configuration item
|
||||
@ -797,7 +797,7 @@ Session | Client | Service | State
|
||||
11 | ::ffff:127.0.0.1 | RWSplit | Session ready for routing
|
||||
-----------------+-----------------+----------------+--------------------------
|
||||
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
This will give a list of client connections.
|
||||
@ -817,7 +817,7 @@ Session 11
|
||||
Connected: Thu Apr 20 09:51:31 2017
|
||||
|
||||
Idle: 82 seconds
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
# Descriptor Control Blocks
|
||||
@ -842,20 +842,20 @@ Descriptor Control Blocks
|
||||
------------------+----------------------------+--------------------+----------
|
||||
DCB | State | Service | Remote
|
||||
------------------+----------------------------+--------------------+----------
|
||||
0x68c0a0 | DCB for listening socket | RWSplit |
|
||||
0x6e23f0 | DCB for listening socket | CLI |
|
||||
0x691710 | DCB for listening socket | SchemaRouter |
|
||||
0x68c0a0 | DCB for listening socket | RWSplit |
|
||||
0x6e23f0 | DCB for listening socket | CLI |
|
||||
0x691710 | DCB for listening socket | SchemaRouter |
|
||||
0x7fffe40130f0 | DCB in the polling loop | CLI | localhost
|
||||
0x6b7540 | DCB for listening socket | RWSplit-Hint |
|
||||
0x6cd020 | DCB for listening socket | ReadConn |
|
||||
0x6b7540 | DCB for listening socket | RWSplit-Hint |
|
||||
0x6cd020 | DCB for listening socket | ReadConn |
|
||||
0x7fffd80130f0 | DCB in the polling loop | RWSplit | ::ffff:127.0.0.1
|
||||
0x7fffdc014590 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc0148d0 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc014c60 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc014ff0 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc014590 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc0148d0 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc014c60 | DCB in the polling loop | RWSplit |
|
||||
0x7fffdc014ff0 | DCB in the polling loop | RWSplit |
|
||||
------------------+----------------------------+--------------------+----------
|
||||
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
A MariaDB MaxScale server that has activity on it will however have many more
|
||||
@ -1028,7 +1028,7 @@ Monitor | Status
|
||||
---------------------+---------------------
|
||||
MySQL-Monitor | Running
|
||||
---------------------+---------------------
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
## Details Of A Particular Monitor
|
||||
@ -1057,7 +1057,7 @@ Slave configured: NO
|
||||
Slave IO running: NO
|
||||
Slave SQL running: NO
|
||||
Master ID: -1
|
||||
Master binlog file:
|
||||
Master binlog file:
|
||||
Master binlog position: 0
|
||||
|
||||
Server: server2
|
||||
@ -1091,7 +1091,7 @@ Master binlog file: binlog.000001
|
||||
Master binlog position: 435
|
||||
|
||||
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
## Shutting Down A Monitor
|
||||
@ -1108,7 +1108,7 @@ Monitor | Status
|
||||
---------------------+---------------------
|
||||
MySQL-Monitor | Stopped
|
||||
---------------------+---------------------
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
## Restarting A Monitor
|
||||
@ -1124,7 +1124,7 @@ Monitor | Status
|
||||
---------------------+---------------------
|
||||
MySQL-Monitor | Running
|
||||
---------------------+---------------------
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
# MaxScale Status Commands
|
||||
@ -1157,7 +1157,7 @@ Pending event queue length averages:
|
||||
1 | Polling | | | |
|
||||
2 | Processing | 1 | 0x6e0dd0 | <202400ms | IN|OUT
|
||||
3 | Polling | | | |
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
The resultant output returns data as to the average thread utilization for the
|
||||
@ -1177,7 +1177,7 @@ MaxScale> show tasks
|
||||
Name | Type | Frequency | Next Due
|
||||
--------------------------+----------+-----------+-------------------------
|
||||
Load Average | Repeated | 10 | Thu Apr 20 10:02:26 2017
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
# Administration Commands
|
||||
@ -1198,7 +1198,7 @@ MySQLAuth | Authenticator | V1.1.0 | 1.1.0 | GA
|
||||
MySQLClient | Protocol | V1.1.0 | 1.1.0 | GA
|
||||
MaxAdminAuth | Authenticator | V2.1.0 | 1.1.0 | GA
|
||||
maxscaled | Protocol | V2.0.0 | 1.1.0 | GA
|
||||
MySQLBackendAuth | Authenticator | V1.0.0 | 1.1.0 | GA
|
||||
MySQLBackendAuth| Authenticator | V1.0.0 | 1.1.0 | GA
|
||||
MySQLBackend | Protocol | V2.0.0 | 1.1.0 | GA
|
||||
mysqlmon | Monitor | V1.5.0 | 3.0.0 | GA
|
||||
schemarouter | Router | V1.0.0 | 2.0.0 | Beta
|
||||
@ -1208,7 +1208,7 @@ readconnroute | Router | V1.1.0 | 2.0.0 | GA
|
||||
cli | Router | V1.0.0 | 2.0.0 | GA
|
||||
----------------+-----------------+---------+-------+-------------------------
|
||||
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
This command provides important version information for the module. Each module
|
||||
@ -1319,7 +1319,7 @@ command.
|
||||
|
||||
```
|
||||
MaxScale> shutdown maxscale
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
# Runtime Configuration Changes
|
||||
@ -1779,7 +1779,7 @@ No of poll completions with descriptors
|
||||
8 0
|
||||
9 0
|
||||
>= 10 0
|
||||
MaxScale>
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
If the "Number of DCBs with pending events" grows rapidly it is an indication
|
||||
@ -1809,38 +1809,38 @@ Average event queue length: 1
|
||||
| Number of events
|
||||
Duration | Queued | Executed
|
||||
---------------+------------+-----------
|
||||
< 100ms | 27 | 26
|
||||
100 - 200ms | 0 | 0
|
||||
200 - 300ms | 0 | 0
|
||||
300 - 400ms | 0 | 0
|
||||
400 - 500ms | 0 | 0
|
||||
500 - 600ms | 0 | 0
|
||||
600 - 700ms | 0 | 0
|
||||
700 - 800ms | 0 | 0
|
||||
800 - 900ms | 0 | 0
|
||||
900 - 1000ms | 0 | 0
|
||||
1000 - 1100ms | 0 | 0
|
||||
1100 - 1200ms | 0 | 0
|
||||
1200 - 1300ms | 0 | 0
|
||||
1300 - 1400ms | 0 | 0
|
||||
1400 - 1500ms | 0 | 0
|
||||
1500 - 1600ms | 0 | 0
|
||||
1600 - 1700ms | 0 | 0
|
||||
1700 - 1800ms | 0 | 0
|
||||
1800 - 1900ms | 0 | 0
|
||||
1900 - 2000ms | 0 | 0
|
||||
2000 - 2100ms | 0 | 0
|
||||
2100 - 2200ms | 0 | 0
|
||||
2200 - 2300ms | 0 | 0
|
||||
2300 - 2400ms | 0 | 0
|
||||
2400 - 2500ms | 0 | 0
|
||||
2500 - 2600ms | 0 | 0
|
||||
2600 - 2700ms | 0 | 0
|
||||
2700 - 2800ms | 0 | 0
|
||||
2800 - 2900ms | 0 | 0
|
||||
2900 - 3000ms | 0 | 0
|
||||
> 3000ms | 0 | 0
|
||||
MaxScale>
|
||||
< 100ms | 27 | 26
|
||||
100 - 200ms | 0 | 0
|
||||
200 - 300ms | 0 | 0
|
||||
300 - 400ms | 0 | 0
|
||||
400 - 500ms | 0 | 0
|
||||
500 - 600ms | 0 | 0
|
||||
600 - 700ms | 0 | 0
|
||||
700 - 800ms | 0 | 0
|
||||
800 - 900ms | 0 | 0
|
||||
900 - 1000ms | 0 | 0
|
||||
1000 - 1100ms | 0 | 0
|
||||
1100 - 1200ms | 0 | 0
|
||||
1200 - 1300ms | 0 | 0
|
||||
1300 - 1400ms | 0 | 0
|
||||
1400 - 1500ms | 0 | 0
|
||||
1500 - 1600ms | 0 | 0
|
||||
1600 - 1700ms | 0 | 0
|
||||
1700 - 1800ms | 0 | 0
|
||||
1800 - 1900ms | 0 | 0
|
||||
1900 - 2000ms | 0 | 0
|
||||
2000 - 2100ms | 0 | 0
|
||||
2100 - 2200ms | 0 | 0
|
||||
2200 - 2300ms | 0 | 0
|
||||
2300 - 2400ms | 0 | 0
|
||||
2400 - 2500ms | 0 | 0
|
||||
2500 - 2600ms | 0 | 0
|
||||
2600 - 2700ms | 0 | 0
|
||||
2700 - 2800ms | 0 | 0
|
||||
2800 - 2900ms | 0 | 0
|
||||
2900 - 3000ms | 0 | 0
|
||||
> 3000ms | 0 | 0
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
The statics are defined in 100ms buckets, with the count of the events that fell
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# Maxbinlogcheck, the MySQL/MariaDB binlog check utility
|
||||
# Maxbinlogcheck, the MariaDB binlog check utility
|
||||
|
||||
# Overview
|
||||
|
||||
Maxbinlogcheck is a command line utility for checking binlogfiles. The files may
|
||||
have been downloaded by the MariaDB MaxScale binlog router or they may be
|
||||
MySQL/MariaDB binlog files stored in a database server acting as a master in a
|
||||
MariaDB binlog files stored in a database server acting as a master in a
|
||||
replication environment. Maxbinlogcheck checks the binlog files against any
|
||||
corruption and stored incomplete transactions and reports a transaction summary
|
||||
after reading all the events. It may optionally truncate the binlog file.
|
||||
|
||||
@ -42,6 +42,7 @@ for details.
|
||||
|
||||
[Here is a list of bugs fixed since the release of MaxScale 2.1.2.](https://jira.mariadb.org/browse/MXS-1212?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.1.3)
|
||||
|
||||
* [MXS-1263](https://jira.mariadb.org/browse/MXS-1263) broken TCP connections are not always cleaned properly
|
||||
* [MXS-1244](https://jira.mariadb.org/browse/MXS-1244) MySQL monitor "detect_replication_lag=true" doesn't work with "mysql51_replication=true"
|
||||
* [MXS-1227](https://jira.mariadb.org/browse/MXS-1227) Nagios Plugins broken by change in output of "show monitors" in 2.1
|
||||
* [MXS-1221](https://jira.mariadb.org/browse/MXS-1221) Nagios plugin scripts does not process -S option properly
|
||||
|
||||
@ -25,7 +25,7 @@ passwd=mypwd
|
||||
|
||||
The module generates the list of databases based on the servers parameter using the connecting client's credentials. The user and passwd parameters define the credentials that are used to fetch the authentication data from the database servers. The credentials used only require the same grants as mentioned in the configuration documentation.
|
||||
|
||||
The list of databases is built by sending a SHOW DATABASES query to all the servers. This requires the user to have at least USAGE and SELECT grants on the databases that need be sharded.
|
||||
The list of databases is built by sending a SHOW DATABASES query to all the servers. This requires the user to have at least USAGE and SELECT grants on the databases that need be sharded.
|
||||
|
||||
If you are connecting directly to a database or have different users on some of the servers, you need to get the authentication data from all the servers. You can control this with the `auth_all_servers` parameter. With this parameter, MariaDB MaxScale forms a union of all the users and their grants from all the servers. By default, the schemarouter will fetch the authentication data from all servers.
|
||||
|
||||
|
||||
@ -121,7 +121,7 @@ When the session ends a report will be written for the session into the logfile
|
||||
|
||||
### Duplicate Data From Your Application Into Cassandra
|
||||
|
||||
The scenario we are using in this example is one in which you have an online gaming application that is designed to work with a MariaDB/MySQL database. The database schema includes a high score table which you would like to have access to in a Cassandra cluster. The application is already using MariaDB MaxScale to connect to a MariaDB Galera cluster, using a service names BubbleGame. The definition of that service is as follows
|
||||
The scenario we are using in this example is one in which you have an online gaming application that is designed to work with a MariaDB database. The database schema includes a high score table which you would like to have access to in a Cassandra cluster. The application is already using MariaDB MaxScale to connect to a MariaDB Galera cluster, using a service names BubbleGame. The definition of that service is as follows
|
||||
```
|
||||
[BubbleGame]
|
||||
type=service
|
||||
@ -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.
|
||||
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.
|
||||
```
|
||||
|
||||
@ -241,7 +241,7 @@ dbserv3 | 192.168.2.3 | 3306 | 0 | Running, Synced, Sl
|
||||
|
||||
A Galera Cluster is a multi-master clustering technology, however the monitor is able
|
||||
to impose false notions of master and slave roles within a Galera Cluster in order to
|
||||
facilitate the use of Galera as if it were a standard MySQL Replication setup.
|
||||
facilitate the use of Galera as if it were a standard MariaDB Replication setup.
|
||||
This is merely an internal MariaDB MaxScale convenience and has no impact on the behavior of the cluster.
|
||||
|
||||
You can control which Galera node is the master server by using the _priority_
|
||||
|
||||
@ -175,7 +175,7 @@ CLI | cli | 2 | 2
|
||||
% maxadmin list servers
|
||||
Servers.
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
Server | Address | Port | Connections | Status
|
||||
Server | Address | Port | Connections | Status
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
dbserv1 | 192.168.2.1 | 3306 | 0 | Running, Synced, Master
|
||||
dbserv2 | 192.168.2.2 | 3306 | 0 | Running, Synced, Slave
|
||||
@ -183,7 +183,7 @@ dbserv3 | 192.168.2.3 | 3306 | 0 | Running, Synced, Sl
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
```
|
||||
|
||||
A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MariaDB MaxScale convenience and has no impact on the behavior of the cluster but does allow the monitor to create these pseudo roles which are utilized by the Read/Write Splitter.
|
||||
A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MariaDB Replication setup. This is merely an internal MariaDB MaxScale convenience and has no impact on the behavior of the cluster but does allow the monitor to create these pseudo roles which are utilized by the Read/Write Splitter.
|
||||
|
||||
You can control which Galera node is the master server by using the _priority_ mechanism of the Galera Monitor module. For more details, read the [Galera Monitor](../Monitors/Galera-Monitor.md) documentation.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ enabled=1
|
||||
gpgcheck=0
|
||||
```
|
||||
|
||||
### Install the software
|
||||
### Install the software
|
||||
|
||||
```
|
||||
# yum install pacemaker corosync crmsh
|
||||
@ -74,7 +74,7 @@ For each node, add all the server names into `/etc/hosts`.
|
||||
|
||||
### Prepare authkey for optional cryptographic use
|
||||
|
||||
On one of the nodes, say node2 run the corosync-keygen utility and follow
|
||||
On one of the nodes, say node2 run the corosync-keygen utility and follow
|
||||
|
||||
```
|
||||
[root@node2 ~]# corosync-keygen
|
||||
@ -263,7 +263,7 @@ The Corosync / Pacemaker cluster is ready to be configured to manage resources.
|
||||
The MariaDB MaxScale init script in `/etc/init.d./maxscale` allows to start, stop, restart and monitor the MariaDB MaxScale process running on the system.
|
||||
|
||||
```
|
||||
[root@node1 ~]# /etc/init.d/maxscale
|
||||
[root@node1 ~]# /etc/init.d/maxscale
|
||||
Usage: /etc/init.d/maxscale {start|stop|status|restart|condrestart|reload}
|
||||
```
|
||||
|
||||
@ -389,7 +389,7 @@ Version: 1.1.10-14.el6_5.3-368c726
|
||||
|
||||
Online: [ node1 node2 node3 ]
|
||||
|
||||
MaxScale (lsb:maxscale): Started node1
|
||||
MaxScale (lsb:maxscale): Started node1
|
||||
```
|
||||
|
||||
### The resource cannot be migrated to node1 for a failure
|
||||
@ -422,7 +422,7 @@ Version: 1.1.10-14.el6_5.3-368c726
|
||||
|
||||
Online: [ node1 node2 node3 ]
|
||||
|
||||
MaxScale (lsb:maxscale): Started node2
|
||||
MaxScale (lsb:maxscale): Started node2
|
||||
|
||||
Failed actions:
|
||||
|
||||
@ -519,9 +519,9 @@ Online: [ node1 node2 node3 ]
|
||||
|
||||
Resource Group: maxscale_service
|
||||
|
||||
maxscale_vip (ocf::heartbeat:IPaddr2): Started node2
|
||||
maxscale_vip (ocf::heartbeat:IPaddr2): Started node2
|
||||
|
||||
MaxScale (lsb:maxscale): Started node2
|
||||
MaxScale (lsb:maxscale): Started node2
|
||||
```
|
||||
|
||||
With both resources on node2, now MariaDB MaxScale service will be reachable via the configured VIP address 192.168.122.125.
|
||||
|
||||
@ -27,11 +27,11 @@ If you already have a SSH key generated, you can skip this next step and go to t
|
||||
To generate a new set of SSH keys, we will use `ssh-keygen`.
|
||||
|
||||
```
|
||||
[root@localhost ~]# ssh-keygen
|
||||
[root@localhost ~]# ssh-keygen
|
||||
Generating public/private rsa key pair.
|
||||
Enter file in which to save the key (/root/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Enter file in which to save the key (/root/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /root/.ssh/id_rsa.
|
||||
Your public key has been saved in /root/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
@ -101,17 +101,17 @@ sync{
|
||||
default.rsyncssh,
|
||||
|
||||
-- This is where the maxscale.cnf file is copied from.
|
||||
source="/etc",
|
||||
source="/etc",
|
||||
|
||||
-- This is the user and host where the maxscale.cnf is copied to.
|
||||
-- Change this to the user and destination host where you want maxscale.cnf to be synchronized to.
|
||||
host="user@192.168.122.100",
|
||||
host="user@192.168.122.100",
|
||||
|
||||
-- This is where the maxscale.cnf is copied to on the remote host.
|
||||
targetdir="/etc",
|
||||
targetdir="/etc",
|
||||
|
||||
-- This is an optional section which defines a custom SSH port. Uncomment to enable.
|
||||
-- ssh={port=2222},
|
||||
-- ssh={port=2222},
|
||||
|
||||
-- These are values passed to rsync. Only change these if you know what you are doing.
|
||||
rsync={
|
||||
@ -139,9 +139,9 @@ settings{
|
||||
|
||||
sync{
|
||||
default.rsyncssh,
|
||||
source="/etc",
|
||||
host="maxuser@192.168.0.50",
|
||||
targetdir="/etc",
|
||||
source="/etc",
|
||||
host="maxuser@192.168.0.50",
|
||||
targetdir="/etc",
|
||||
rsync={
|
||||
compress=true,
|
||||
_extra = {[[--filter=+ *maxscale.cnf]],
|
||||
@ -153,9 +153,9 @@ rsync={
|
||||
|
||||
sync{
|
||||
default.rsyncssh,
|
||||
source="/etc",
|
||||
host="syncuser@192.168.122.105",
|
||||
targetdir="/etc",
|
||||
source="/etc",
|
||||
host="syncuser@192.168.122.105",
|
||||
targetdir="/etc",
|
||||
rsync={
|
||||
compress=true,
|
||||
_extra = {[[--filter=+ *maxscale.cnf]],
|
||||
|
||||
@ -16,7 +16,7 @@ Currently the user can connect to maxinfo from any remote IP and to localhost as
|
||||
type=service
|
||||
router=maxinfo
|
||||
user=monitor
|
||||
passwd=EBD2F49C3B375812A8CDEBA632ED8BBC
|
||||
passwd=EBD2F49C3B375812A8CDEBA632ED8BBC
|
||||
```
|
||||
|
||||
The listener section defines the protocol, port and other information needed to create a listener for the service. To listen on a port using the MySQL protocol a section as shown below should be added to the configuration file.
|
||||
@ -61,7 +61,7 @@ The maxinfo supports a small subset of SQL statements in addition to the MySQL s
|
||||
% mysqladmin -hmaxscale.mariadb.com -P9003 -umonitor -pxyz ping
|
||||
mysqld is alive
|
||||
% mysqladmin -hmaxscale.mariadb.com -P9003 -umonitor -pxyz status
|
||||
Uptime: 72 Threads: 1 Sessions: 11
|
||||
Uptime: 72 Threads: 1 Sessions: 11
|
||||
%
|
||||
```
|
||||
|
||||
@ -168,7 +168,7 @@ mysql> show status;
|
||||
+---------------------------+-------+
|
||||
22 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show services
|
||||
@ -191,7 +191,7 @@ mysql> show services;
|
||||
+----------------+----------------+--------------+----------------+
|
||||
8 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
The show services command does not accept a like clause and will ignore any like clause that is given.
|
||||
@ -217,7 +217,7 @@ mysql> show listeners;
|
||||
+----------------+-----------------+-----------+------+---------+
|
||||
9 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
The show listeners command will ignore any like clause passed to it.
|
||||
@ -245,7 +245,7 @@ mysql> show sessions;
|
||||
+-----------+---------------+----------------+---------------------------+
|
||||
11 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show clients
|
||||
@ -262,7 +262,7 @@ mysql> show clients;
|
||||
+-----------+---------------+---------+---------------------------+
|
||||
2 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show servers
|
||||
@ -281,7 +281,7 @@ mysql> show servers;
|
||||
+---------+-----------+------+-------------+---------+
|
||||
4 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show modules
|
||||
@ -306,7 +306,7 @@ mysql> show modules;
|
||||
+----------------+-------------+---------+-------------+----------------+
|
||||
10 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show monitors
|
||||
@ -367,7 +367,7 @@ mysql> show eventTimes;
|
||||
+---------------+-------------------+---------------------+
|
||||
30 rows in set (0.02 sec)
|
||||
|
||||
mysql>
|
||||
mysql>
|
||||
```
|
||||
|
||||
Each row represents a time interval, in 100ms increments, with the counts representing the number of events that were in the event queue for the length of time that row represents and the number of events that were executing of the time indicated by the row.
|
||||
@ -422,7 +422,7 @@ $ curl http://maxscale.mariadb.com:8003/status
|
||||
{ "Variable_name" : "Max_event_queue_length", "Value" : 1},
|
||||
{ "Variable_name" : "Max_event_queue_time", "Value" : 0},
|
||||
{ "Variable_name" : "Max_event_execution_time", "Value" : 1}]
|
||||
$
|
||||
$
|
||||
```
|
||||
|
||||
## Services
|
||||
@ -496,7 +496,7 @@ $ curl http://maxscale.mariadb.com:8003/sessions
|
||||
{ "Session" : "0x1a5c0b0", "Client" : , "Service" : "Filter Service", "State" : "Listener Session"},
|
||||
{ "Session" : "0x1a5c530", "Client" : , "Service" : "Split Service", "State" : "Listener Session"},
|
||||
{ "Session" : "0x19ac1c0", "Client" : , "Service" : "Test Service", "State" : "Listener Session"}]
|
||||
$
|
||||
$
|
||||
```
|
||||
|
||||
## Clients
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
# Setting up MariaDB MaxScale
|
||||
|
||||
This document is designed as a quick introduction to setting up MariaDB MaxScale
|
||||
in an environment in which you have either a MySQL Master-Slave replication cluster
|
||||
in an environment in which you have either a MariaDB Master-Slave replication cluster
|
||||
with one master and multiple slave servers or a multi-node Galera cluster.
|
||||
The process of setting and configuring MariaDB MaxScale will be covered within this document.
|
||||
|
||||
The installation and configuration of the MySQL Replication or the Galera cluster
|
||||
The installation and configuration of the MariaDB Replication or the Galera cluster
|
||||
will not be covered nor will any discussion of installation management tools
|
||||
to handle automated or semi-automated failover of the replication cluster.
|
||||
The [Setting Up Replication](https://mariadb.com/kb/en/mariadb/setting-up-replication/)
|
||||
@ -109,7 +109,7 @@ The best way to describe this process is with an example.
|
||||
|
||||
User `'jdoe'@'192.168.0.200` has the following grant on the cluster:
|
||||
`GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'192.168.0.200'`.
|
||||
When the user connects directly to the server it will see it as
|
||||
When the user connects directly to the server it will see it as
|
||||
`'jdoe'@'192.168.0.200` connecting to the server and it will match
|
||||
the grant for `'jdoe'@'192.168.0.200`.
|
||||
|
||||
@ -153,8 +153,8 @@ The configuration file creation is covered in different tutorials.
|
||||
|
||||
### Master-Slave cluster
|
||||
|
||||
* [MySQL Replication Connection Routing Tutorial](MySQL-Replication-Connection-Routing-Tutorial.md)
|
||||
* [MySQL Replication Read-Write Splitting Tutorial](MySQL-Replication-Read-Write-Splitting-Tutorial.md)
|
||||
* [MariaDB Replication Connection Routing Tutorial](MySQL-Replication-Connection-Routing-Tutorial.md)
|
||||
* [MariaDB Replication Read-Write Splitting Tutorial](MySQL-Replication-Read-Write-Splitting-Tutorial.md)
|
||||
|
||||
### Galera cluster
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Connection Routing with MySQL Replication
|
||||
# Connection Routing with MariaDB Replication
|
||||
|
||||
# Environment & Solution Space
|
||||
|
||||
@ -21,7 +21,7 @@ A global, `[maxscale]`, section is included within every MariaDB MaxScale config
|
||||
threads=4
|
||||
```
|
||||
|
||||
Since we are using MySQL Replication and connection routing we want two different ports to which the client application can connect; one that will be directed to the current master within the replication cluster and another that will load balance between the slaves. To achieve this within MariaDB MaxScale we need to define two services in the ini file; one for the read/write operations that should be executed on the master server and another for connections to one of the slaves. Create a section for each in your MariaDB MaxScale configuration file and set the type to service, the section names are the names of the services themselves and should be meaningful to the administrator. Avoid using whitespace in the section names.
|
||||
Since we are using MariaDB Replication and connection routing we want two different ports to which the client application can connect; one that will be directed to the current master within the replication cluster and another that will load balance between the slaves. To achieve this within MariaDB MaxScale we need to define two services in the ini file; one for the read/write operations that should be executed on the master server and another for connections to one of the slaves. Create a section for each in your MariaDB MaxScale configuration file and set the type to service, the section names are the names of the services themselves and should be meaningful to the administrator. Avoid using whitespace in the section names.
|
||||
|
||||
```
|
||||
[Write-Service]
|
||||
@ -207,7 +207,7 @@ CLI | cli | 2 | 2
|
||||
|
||||
Servers.
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
Server | Address | Port | Connections | Status
|
||||
Server | Address | Port | Connections | Status
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
dbserv1 | 192.168.2.1 | 3306 | 0 | Running, Slave
|
||||
dbserv2 | 192.168.2.2 | 3306 | 0 | Running, Master
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Read/Write Splitting with MySQL Replication
|
||||
# Read/Write Splitting with MariaDB Replication
|
||||
|
||||
## Environment & Solution Space
|
||||
|
||||
@ -228,7 +228,7 @@ Servers.
|
||||
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
|
||||
Server | Address | Port | Connections | Status
|
||||
Server | Address | Port | Connections | Status
|
||||
|
||||
-------------------+-----------------+-------+-------------+--------------------
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ that can be run from a command line to check the status or a host or service.
|
||||
Nagios uses the results from plugins to determine the current status of hosts and
|
||||
services on your network.
|
||||
Nagios core executes a plugin whenever there is a need to check the status
|
||||
of a service or host.
|
||||
of a service or host.
|
||||
|
||||
While MariaDB MaxScale resources and status can be monitored via CLI using
|
||||
maxadmin commands, Nagios Plugin provides an automated way for system administration
|
||||
@ -31,7 +31,7 @@ details on respective resources.
|
||||
Current resources are: modules, services, listeners, servers, sessions, filters.
|
||||
|
||||
3. check_maxscale_monitor.pl: This command provides you status of the configured
|
||||
monitor modules on MariaDB MaxScale server.
|
||||
monitor modules on MariaDB MaxScale server.
|
||||
|
||||
In order to use these scripts on your Nagios Server, you need to copy them
|
||||
from the MariaDB MaxScale binary package or download them from source tree on GitHub.
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# Data archiving with Mqfilter and Tee filters
|
||||
|
||||
This tutorial gives a quick look into how you can combine various filters to create
|
||||
This tutorial gives a quick look into how you can combine various filters to create
|
||||
systems for archiving data for analysis. The aim of this tutorial is to show
|
||||
what can be done with MariaDB MaxScale's filters rather than demonstrate a proven method
|
||||
of archiving data. For this tutorial you will need two MariaDB/MySQL servers, one for
|
||||
of archiving data. For this tutorial you will need two MariaDB servers, one for
|
||||
archiving the data and one for actual use, a RabbitMQ server and a MariaDB MaxScale server.
|
||||
For testing purposes some of these can locate on the same server but for actual
|
||||
use, an HA solution is recommended.
|
||||
@ -21,14 +21,14 @@ making the archive server a true archive of all data.
|
||||
|
||||
The installation of MariaDB MaxScale is covered in the Installation chapter of the [MariaDB MaxScale Tutorial](MaxScale-Tutorial.md).
|
||||
|
||||
## Setting up the MariaDB/MySQL servers
|
||||
## Setting up the MariaDB servers
|
||||
|
||||
Since the archive server will not replicate from the main server, we don't need to
|
||||
set up replication between the two. The only thing we need to do is to create the
|
||||
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
|
||||
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#creating-database-users).
|
||||
|
||||
## Setting up RabbitMQ server
|
||||
@ -322,7 +322,7 @@ sudo 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
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
# MariaDB MaxScale as a Binlog Server
|
||||
MariaDB MaxScale is a dynamic data routing platform that sits between a database layer and the clients of that database. However, the binlog router described here is somewhat different to that original concept, moving MariaDB MaxScale down to play a role within the database layer itself.
|
||||
|
||||
In a traditional MySQL replication setup a single master server is created and a set of slaves MySQL instances are configured to pull the binlog files from that master to the slaves. There are some problems, however, in this setup; when the number of slaves grows, an increasing load caused by the serving of binlogs to each slave, is placed on the master. When the master server fails, some action must be performed on every slave server before a new server can become the master server.
|
||||
In a traditional MariaDB replication setup a single master server is created and a set of slaves MariaDB instances are configured to pull the binlog files from that master to the slaves. There are some problems, however, in this setup; when the number of slaves grows, an increasing load caused by the serving of binlogs to each slave, is placed on the master. When the master server fails, some action must be performed on every slave server before a new server can become the master server.
|
||||
|
||||
Introducing a proxy layer between the master server and the slave servers can improve the situation, by reducing the load on the master to simply serving the proxy layer rather than all of the slaves. The slaves only need to be aware of the proxy layer and not of the real master server. Removing the need for the slaves to have knowledge of the actual master, greatly simplifies the process of replacing a failed master within a replication environment.
|
||||
|
||||
## MariaDB/MySQL as a Binlog Server
|
||||
## MariaDB as a Binlog Server
|
||||
The most obvious solution to the requirement for a proxy layer within a replication environment is to use a MariaDB or MySQL database instance. The database server is designed to allow this, since a slave server is able to be configured such that it will produce binary logs for updates it has itself received via replication from the master server. This is done with the *log_slave_updates* configuration option of the server. In this case the server is known as an intermediate master, it is simultaneously a slave to the real master and a master to the other slaves in the configuration.
|
||||
|
||||
Using an intermediate master does not, however, solve all the problems and introduces some new ones, due to the way replication is implemented. A slave server reads the binary log data and creates a relay log from that binary log. This log provides a source of SQL statements, which are executed within the slave in order to make the same changes to the databases on the slaves as were made on the master. If the *log_slave_updates* option has been enabled, new binary log entries are created for the statements executed from the relay log.
|
||||
@ -348,7 +348,7 @@ Master_SSL_Verify_Server_Cert: No
|
||||
|
||||
# Binlog router compatibility
|
||||
|
||||
Binlog Router Plugin is compatible with MySQL 5.6 and MariaDB 5.5, the current default.
|
||||
Binlog Router Plugin is compatible with MariaDB 5.5 and MySQL 5.6, the current default.
|
||||
|
||||
In order to use it with MySQL 5.6, the *GTID_MODE* setting must be OFF and connecting slaves must not use *MASTER_AUTO_POSITION = 1* option.
|
||||
|
||||
|
||||
@ -8,11 +8,11 @@ MariaDB MaxScale will appear to the client as a database server with the combina
|
||||
|
||||
## Environment & Solution Space
|
||||
|
||||
This document is designed as a simple tutorial on schema-based sharding using MariaDB MaxScale in an environment in which you have two servers. The object of this tutorial is to have a system that, to the client side, acts like a single MySQL database but actually is sharded between the two servers.
|
||||
This document is designed as a simple tutorial on schema-based sharding using MariaDB MaxScale in an environment in which you have two servers. The object of this tutorial is to have a system that, to the client side, acts like a single MariaDB database but actually is sharded between the two servers.
|
||||
|
||||
The database users should be configured according to [the configuration guide](../Getting-Started/Configuration-Guide.md). The [MaxScale Tutorial](MaxScale-Tutorial.md) contains easy to follow instructions on how to set up MaxScale.
|
||||
|
||||
This tutorial will assume the user is using of the binary distributions available and has installed this in the default location. The process of configuring MariaDB MaxScale will be covered within this document. The installation and configuration of the MySQL servers will not be covered in-depth.
|
||||
|
||||
This tutorial will assume the user is using of the binary distributions available and has installed this in the default location. The process of configuring MariaDB MaxScale will be covered within this document. The installation and configuration of the MariaDB servers will not be covered in-depth.
|
||||
|
||||
## Preparing MaxScale
|
||||
|
||||
|
||||
@ -46,14 +46,14 @@ parameter to the service definition.
|
||||
|
||||
## Persistent Connections
|
||||
|
||||
The MySQL session state is reset in MaxScale 2.1 for persistent
|
||||
The MariaDB session state is reset in MaxScale 2.1 for persistent
|
||||
connections. This means that any modifications to the session state (default
|
||||
database, user variable etc.) will not survive if the connection is put into the
|
||||
connection pool. For most users, this is the expected behavior.
|
||||
|
||||
## User Data Cache
|
||||
|
||||
The location of the MySQL user data cache was moved from
|
||||
The location of the MariaDB user data cache was moved from
|
||||
`/var/cache/maxscale/<Service>` to `/var/cache/maxscale/<Service>/<Listener>`.
|
||||
|
||||
## Galeramon Monitoring Algorithm
|
||||
|
||||
@ -37,7 +37,7 @@ filter(){
|
||||
# and we add the current date to the end of the 2 lines in the titleblock
|
||||
#date=$(date +"%B %e, %Y")
|
||||
printf -v date "%(%B %e, %Y)T"
|
||||
#awk ' /^$/ {p++} p==1{printf "%% %s\n", "'"$date"'";p++} !p{printf "%% "} {print} '
|
||||
#awk ' /^$/ {p++} p==1{printf "%% %s\n", "'"$date"'";p++} !p{printf "%% "} {print} '
|
||||
awk ' NR==1{ printf "%% " } # put % in front of first line
|
||||
NR==2{ printf " " } # put some space in front of 2nd line. pandoc requires this to continue the title
|
||||
NR==3{ printf "%% %s", "'"$date"'" } # 3rd line becomes the date.
|
||||
@ -49,10 +49,10 @@ filter(){
|
||||
|
||||
pandoc_vars=(
|
||||
-V fontsize=12pt
|
||||
-V version=1.10
|
||||
-V geometry:margin=1in
|
||||
-V version=1.10
|
||||
-V geometry:margin=1in
|
||||
--toc
|
||||
-t latex
|
||||
-t latex
|
||||
--latex-engine=xelatex
|
||||
--template="$template"
|
||||
)
|
||||
|
||||
@ -33,7 +33,15 @@ opts = parser.parse_args(sys.argv[1:])
|
||||
|
||||
def parse_field(row):
|
||||
res = dict()
|
||||
name = row[1].lower().split('(')[0]
|
||||
parts = row[1].lower().split('(')
|
||||
name = parts[0]
|
||||
|
||||
res["real_type"] = name
|
||||
|
||||
if len(parts) > 1:
|
||||
res["length"] = int(parts[1].split(')')[0])
|
||||
else:
|
||||
res["length"] = -1
|
||||
|
||||
if name in ("date", "datetime", "time", "timestamp", "year", "tinytext", "text",
|
||||
"mediumtext", "longtext", "char", "varchar", "enum", "set"):
|
||||
|
||||
@ -211,12 +211,40 @@ bool json_extract_field_names(const char* filename, TABLE_CREATE *table)
|
||||
}
|
||||
|
||||
json_t *name = json_object_get(val, "name");
|
||||
|
||||
if (name && json_is_string(name))
|
||||
{
|
||||
const char *name_str = json_string_value(name);
|
||||
|
||||
if (not_generated_field(name_str))
|
||||
{
|
||||
table->column_names[columns++] = MXS_STRDUP_A(name_str);
|
||||
table->column_names[columns] = MXS_STRDUP_A(name_str);
|
||||
|
||||
json_t* value;
|
||||
|
||||
if ((value = json_object_get(val, "real_type")) && json_is_string(value))
|
||||
{
|
||||
table->column_types[columns] = MXS_STRDUP_A(json_string_value(value));
|
||||
}
|
||||
else
|
||||
{
|
||||
table->column_types[columns] = MXS_STRDUP_A("unknown");
|
||||
MXS_WARNING("No \"real_type\" value defined. "
|
||||
"Treating as unknown type field.");
|
||||
}
|
||||
|
||||
if ((value = json_object_get(val, "length")) && json_is_integer(value))
|
||||
{
|
||||
table->column_lengths[columns] = json_integer_value(value);
|
||||
}
|
||||
else
|
||||
{
|
||||
table->column_lengths[columns] = -1;
|
||||
MXS_WARNING("No \"length\" value defined. "
|
||||
"Treating as default length field.");
|
||||
}
|
||||
|
||||
columns++;
|
||||
}
|
||||
}
|
||||
else
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user