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

Update documentation

Browse Source
This commit is contained in:
Johan Wikman 2017-05-18 10:56:34 +03:00
parent 8a2112cce6
commit ed97b4b22c
18 changed files with 37 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/Authenticators/Authentication-Modules.md
View File

@ -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)

4
Documentation/Documentation-Contents.md
View File

@ -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)

12
Documentation/Getting-Started/Configuration-Guide.md
View File

@ -1137,7 +1137,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.
@ -1355,12 +1355,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.
@ -1399,10 +1399,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:

6
Documentation/Getting-Started/MariaDB-MaxScale-Installation-Guide.md
View File

@ -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

2
Documentation/Protocols/CDC.md
View File

@ -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.

2
Documentation/Protocols/CDC_users.md
View File

@ -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

4
Documentation/Reference/MaxAdmin.md
View File

@ -677,7 +677,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?
@ -1197,7 +1197,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

4
Documentation/Reference/MaxBinlogCheck.md
View File

@ -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.

2
Documentation/Tutorials/Filter-Tutorial.md
View File

@ -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

2
Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md
View File

@ -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_

2
Documentation/Tutorials/Galera-Cluster-Read-Write-Splitting-Tutorial.md
View File

@ -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.

8
Documentation/Tutorials/MaxScale-Tutorial.md
View File

@ -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/)
@ -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

4
Documentation/Tutorials/MySQL-Replication-Connection-Routing-Tutorial.md
View File

@ -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]

2
Documentation/Tutorials/MySQL-Replication-Read-Write-Splitting-Tutorial.md
View File

@ -1,4 +1,4 @@
# Read/Write Splitting with MySQL Replication
# Read/Write Splitting with MariaDB Replication
## Environment & Solution Space

4
Documentation/Tutorials/RabbitMQ-And-Tee-Archiving.md
View File

@ -3,7 +3,7 @@
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,7 +21,7 @@ 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

6
Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md
View File

@ -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.

4
Documentation/Tutorials/Simple-Sharding-Tutorial.md
View File

@ -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

4
Documentation/Upgrading/Upgrading-To-MaxScale-2.1.md
View File

@ -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