2.1 doc johan (#126)
* Update Documentation-Contents.md * Update SchemaRouter-technical.md * Update Plugin-development-guide.md * Update Replication-Proxy-Binlog-Router-Tutorial.md * Update MaxScale-HA-with-lsyncd.md * Update MaxScale-Information-Schema.md * Update Galera-Cluster-Read-Write-Splitting-Tutorial.md * Update GSSAPI-Authenticator.md
This commit is contained in:
Johan Wikman
GitHub
parent
695ba19965
commit
09086994bf
@ -19,7 +19,7 @@ the _kadmin_ or _kadmin.local_ tools.
|
||||
kadmin.local -q "addprinc -nokey mariadb/example.com@EXAMPLE.COM"
|
||||
```
|
||||
|
||||
The _-nokey_ option will make the principal a passwordless one. This allows the
|
||||
The `-nokey` option will make the principal a passwordless one. This allows the
|
||||
_maxscale_ user to acquire a ticket for it without a password being prompted.
|
||||
|
||||
The next step is to export this principal into the Kerberos keytab file.
|
||||
|
||||
@ -8,19 +8,19 @@ on, so the APIs of these two are discussed in detail.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Introduction](#introduction)
|
||||
* [Module categories](#module-categories)
|
||||
* [Common definitions and headers](#common-definitions-and-headers)
|
||||
1. [Module information container](#module-information-container)
|
||||
* [Module API](#module-api)
|
||||
1. [Overview](#overview)
|
||||
* [General module management](#general-module-management)
|
||||
* [Protocol](#protocol)
|
||||
* [Authenticator](#authenticator)
|
||||
* [Filter and Router](#filter-and-router)
|
||||
* [Monitor](#monitor)
|
||||
* [Introduction](#introduction)
|
||||
* [Module categories](#module-categories)
|
||||
* [Common definitions and headers](#common-definitions-and-headers)
|
||||
* [Module information container](#module-information-container)
|
||||
* [Module API](#module-api)
|
||||
* [Overview](#overview)
|
||||
* [General module management](#general-module-management)
|
||||
* [Protocol](#protocol)
|
||||
* [Authenticator](#authenticator)
|
||||
* [Filter and Router](#filter-and-router)
|
||||
* [Monitor](#monitor)
|
||||
* [Compiling, installing and running](#compiling-installing-and-running)
|
||||
1. [Hands-on example: RoundRobinRouter](#hands-on-example-roundrobinrouter)
|
||||
* [Hands-on example: RoundRobinRouter](#hands-on-example-roundrobinrouter)
|
||||
* [Summary and conclusion](#summary-and-conclusion)
|
||||
|
||||
## Introduction
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
#SchemaRouter Router - Technical Overview
|
||||
# SchemaRouter Router - Technical Overview
|
||||
|
||||
This document is designed with a developer's point-of-view in mind. It explains the lifecycle of the module and details about its internal workings. It refers to the source code which can be found at [GitHub](https://github.com/mariadb-corporation/MaxScale).
|
||||
|
||||
|
||||
@ -1,12 +1,10 @@
|
||||
|
||||
[Search page for MariaDB MaxScale Documentation](http://mariadb-corporation.github.io/MaxScale/Search/)
|
||||
|
||||
# Contents
|
||||
|
||||
## About MariaDB MaxScale
|
||||
|
||||
- [About MariaDB MaxScale](About/About-MaxScale.md)
|
||||
- [Release Notes](Release-Notes/MaxScale-2.1.1-Release-Notes.md)
|
||||
- [Release Notes](Release-Notes/MaxScale-2.1.3-Release-Notes.md)
|
||||
- [Changelog](Changelog.md)
|
||||
- [Limitations](About/Limitations.md)
|
||||
|
||||
@ -23,8 +21,6 @@
|
||||
## Reference
|
||||
|
||||
- [MaxAdmin - Admin Interface](Reference/MaxAdmin.md)
|
||||
- [How Errors are Handled in MariaDB MaxScale](Reference/How-errors-are-handled-in-MaxScale.md)
|
||||
- [Debug and Diagnostic Support](Reference/Debug-And-Diagnostic-Support.md)
|
||||
- [Routing Hints](Reference/Hint-Syntax.md)
|
||||
- [MaxBinlogCheck](Reference/MaxBinlogCheck.md)
|
||||
- [MaxScale REST API](REST-API/API.md)
|
||||
@ -39,51 +35,61 @@ The main tutorial for MariaDB MaxScale consist of setting up MariaDB MaxScale fo
|
||||
These tutorials are for specific use cases and module combinations.
|
||||
|
||||
- [Administration Tutorial](Tutorials/Administration-Tutorial.md)
|
||||
- [Avro Router Tutorial](Tutorials/Avrorouter-Tutorial.md)
|
||||
- [Filter Tutorial](Tutorials/Filter-Tutorial.md)
|
||||
- [MariaDB MaxScale Information Schema Tutorial](Tutorials/MaxScale-Information-Schema.md)
|
||||
- [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)
|
||||
- [Replication Proxy with the Binlog Router Tutorial](Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md)
|
||||
- [RabbitMQ Setup and MariaDB MaxScale Integration Tutorial](Tutorials/RabbitMQ-Setup-And-MaxScale-Integration.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 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)
|
||||
- [RabbitMQ Setup and MariaDB MaxScale Integration Tutorial](Tutorials/RabbitMQ-Setup-And-MaxScale-Integration.md)
|
||||
- [Replication Proxy with the Binlog Router Tutorial](Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md)
|
||||
- [Simple Schema Sharding Tutorial](Tutorials/Simple-Sharding-Tutorial.md)
|
||||
|
||||
Here are tutorials on monitoring and managing MariaDB MaxScale in cluster environments.
|
||||
|
||||
- [Nagios Plugins for MariaDB MaxScale Tutorial](Tutorials/Nagios-Plugins.md)
|
||||
- [MariaDB MaxScale HA with Corosync-Pacemaker](Tutorials/MaxScale-HA-with-Corosync-Pacemaker.md)
|
||||
- [MariaDB MaxScale HA with Lsyncd](Tutorials/MaxScale-HA-with-lsyncd.md)
|
||||
|
||||
- [Nagios Plugins for MariaDB MaxScale Tutorial](Tutorials/Nagios-Plugins.md)
|
||||
|
||||
## Routers
|
||||
|
||||
The routing module is the core of a MariaDB MaxScale service. The router documentation
|
||||
contains all module specific configuration options and detailed explanations
|
||||
of their use.
|
||||
|
||||
- [Read Write Split](Routers/ReadWriteSplit.md)
|
||||
- [Read Connection Router](Routers/ReadConnRoute.md)
|
||||
- [Schemarouter](Routers/SchemaRouter.md)
|
||||
- [Binlogrouter](Routers/Binlogrouter.md)
|
||||
- [Avrorouter](Routers/Avrorouter.md)
|
||||
- [Binlogrouter](Routers/Binlogrouter.md)
|
||||
- [Read Connection Router](Routers/ReadConnRoute.md)
|
||||
- [Read Write Split](Routers/ReadWriteSplit.md)
|
||||
- [Schemarouter](Routers/SchemaRouter.md)
|
||||
|
||||
There are also two diagnostic routing modules. The CLI is for MaxAdmin and
|
||||
the Debug CLI client for Telnet.
|
||||
|
||||
- [CLI](Routers/CLI.md)
|
||||
- [Debug CLI](Routers/Debug-CLI.md)
|
||||
|
||||
## Filters
|
||||
|
||||
Here are detailed documents about the filters MariaDB MaxScale offers. They contain configuration guides and example use cases. Before reading these, you should have read the filter tutorial so that you know how they work and how to configure them.
|
||||
|
||||
- [Cache](Filters/Cache.md)
|
||||
- [Consistent Critical Read Filter](Filters/CCRFilter.md)
|
||||
- [Database Firewall Filter](Filters/Database-Firewall-Filter.md)
|
||||
- [Insert Stream Filter](Filters/Insert-Stream-Filter.md)
|
||||
- [Luafilter](Filters/Luafilter.md)
|
||||
- [Masking Filter](Filters/Masking.md)
|
||||
- [Maxrows Filter](Filters/Maxrows.md)
|
||||
- [Named Server Filter](Filters/Named-Server-Filter.md)
|
||||
- [Query Log All](Filters/Query-Log-All-Filter.md)
|
||||
- [RabbitMQ Filter](Filters/RabbitMQ-Filter.md)
|
||||
- [Regex Filter](Filters/Regex-Filter.md)
|
||||
- [Tee Filter](Filters/Tee-Filter.md)
|
||||
- [Top N Filter](Filters/Top-N-Filter.md)
|
||||
- [Database Firewall Filter](Filters/Database-Firewall-Filter.md)
|
||||
- [RabbitMQ Filter](Filters/RabbitMQ-Filter.md)
|
||||
- [Named Server Filter](Filters/Named-Server-Filter.md)
|
||||
- [Luafilter](Filters/Luafilter.md)
|
||||
- [Insert Stream Filter](Filters/Insert-Stream-Filter.md)
|
||||
- [Transaction Performance Monitoring Filter](Filters/Transaction-Performance-Monitoring-Filter.md)
|
||||
|
||||
## Monitors
|
||||
|
||||
@ -93,9 +99,10 @@ Common options for all monitor modules.
|
||||
|
||||
Module specific documentation.
|
||||
|
||||
- [MySQL Monitor](Monitors/MySQL-Monitor.md)
|
||||
- [Aurora Monitor](Monitors/Aurora-Monitor.md)
|
||||
- [Galera Monitor](Monitors/Galera-Monitor.md)
|
||||
- [Multi-Master Monitor](Monitors/MM-Monitor.md)
|
||||
- [MySQL Monitor](Monitors/MySQL-Monitor.md)
|
||||
- [MySQL Cluster Monitor](Monitors/NDB-Cluster-Monitor.md)
|
||||
|
||||
## Protocols
|
||||
@ -120,8 +127,6 @@ document.
|
||||
|
||||
## Design Documents
|
||||
|
||||
- [Core Objects Design (in development)](http://mariadb-corporation.github.io/MaxScale/Design-Documents/core-objects-html-docs)
|
||||
- [Binlog Router Design (in development)](http://mariadb-corporation.github.io/MaxScale/Design-Documents/binlog-router-html-docs)
|
||||
- [DCB States (to be replaced in StarUML)](Design-Documents/DCB-States.pdf)
|
||||
- [Schema Sharding Router Technical Documentation](Design-Documents/SchemaRouter-technical.md)
|
||||
- [Plugin development guide](Design-Documents/Plugin-development-guide.md)
|
||||
|
||||
@ -12,7 +12,7 @@ Once you have MariaDB MaxScale installed and the database users created, we can
|
||||
|
||||
## Creating Your MariaDB MaxScale Configuration
|
||||
|
||||
MariaDB MaxScale configuration is held in an ini file that is located in the file maxscale.cnf in the directory /etc, if you have installed in the default location then this file is available in /etc/maxscale.cnf. This is not created as part of the installation process and must be manually created. A template file does exist within the /usr/share/maxscale directory that may be use as a basis for your configuration.
|
||||
MariaDB MaxScale configuration is held in an ini file that is located in the file `maxscale.cnf` in the directory `/etc`, if you have installed in the default location then this file is available in `/etc/maxscale.cnf`. This is not created as part of the installation process and must be manually created. A template file does exist within the `/usr/share/maxscale` directory that may be use as a basis for your configuration.
|
||||
|
||||
A global, maxscale, section is included within every MariaDB MaxScale configuration file; this is used to set the values of various MariaDB MaxScale wide parameters, perhaps the most important of these is the number of threads that MariaDB MaxScale will use to execute the code that forwards requests and handles responses for clients.
|
||||
|
||||
@ -71,7 +71,7 @@ type=listener
|
||||
service=Splitter Service
|
||||
```
|
||||
|
||||
A listener must also define the protocol module it will use for the incoming network protocol, currently this should be the MySQLClient protocol for all database listeners. The listener may then supply a network port to listen on and/or a socket within the file system.
|
||||
A listener must also define the protocol module it will use for the incoming network protocol, currently this should be the `MySQLClient` protocol for all database listeners. The listener may then supply a network port to listen on and/or a socket within the file system.
|
||||
|
||||
```
|
||||
[Splitter Listener]
|
||||
@ -84,7 +84,7 @@ socket=/tmp/ClusterMaster
|
||||
|
||||
An address parameter may be given if the listener is required to bind to a particular network address when using hosts with multiple network addresses. The default behavior is to listen on all network interfaces.
|
||||
|
||||
The next stage is the configuration is to define the server information. This defines how to connect to each of the servers within the cluster, again a section is created for each server, with the type set to server, the network address and port to connect to and the protocol to use to connect to the server. Currently the protocol module for all database connections in MySQLBackend.
|
||||
The next stage is the configuration is to define the server information. This defines how to connect to each of the servers within the cluster, again a section is created for each server, with the type set to server, the network address and port to connect to and the protocol to use to connect to the server. Currently the protocol module for all database connections in `MySQLBackend`.
|
||||
|
||||
```
|
||||
[dbserv1]
|
||||
@ -119,7 +119,7 @@ passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
|
||||
As with the password definition in the server either plain text or encrypted passwords may be used.
|
||||
|
||||
This monitor module will assign one node within the Galera Cluster as the current master and other nodes as slave. Only those nodes that are active members of the cluster are considered when making the choice of master node. Normally the master node will be the node with the lowest value of the status variable, WSREP_LOCAL_INDEX. When cluster membership changes a new master may be elected. In order to prevent changes of the node that is currently master, a parameter can be added to the monitor that will result in the current master remaining as master even if a node with a lower value of WSREP_LOCAL_INDEX joins the cluster. This parameter is called disable_master_failback.
|
||||
This monitor module will assign one node within the Galera Cluster as the current master and other nodes as slave. Only those nodes that are active members of the cluster are considered when making the choice of master node. Normally the master node will be the node with the lowest value of the status variable, `WSREP_LOCAL_INDEX`. When cluster membership changes a new master may be elected. In order to prevent changes of the node that is currently master, a parameter can be added to the monitor that will result in the current master remaining as master even if a node with a lower value of `WSREP_LOCAL_INDEX` joins the cluster. This parameter is called `disable_master_failback`.
|
||||
|
||||
```
|
||||
[Galera Monitor]
|
||||
@ -159,7 +159,7 @@ or
|
||||
% service maxscale start
|
||||
```
|
||||
|
||||
Check the error log in /var/log/maxscale to see if any errors are detected in the configuration file and to confirm MariaDB MaxScale has been started. Also the maxadmin command may be used to confirm that MariaDB MaxScale is running and the services, listeners etc have been correctly configured.
|
||||
Check the error log in `/var/log/maxscale` to see if any errors are detected in the configuration file and to confirm MariaDB MaxScale has been started. Also the maxadmin command may be used to confirm that MariaDB MaxScale is running and the services, listeners etc have been correctly configured.
|
||||
|
||||
```
|
||||
% maxadmin list services
|
||||
@ -199,4 +199,4 @@ CLI | maxscaled | localhost | 6603 | Running
|
||||
---------------------+--------------------+-----------------+-------+--------
|
||||
```
|
||||
|
||||
MariaDB MaxScale is now ready to start accepting client connections and routing them to the master or slaves within your cluster. Other configuration options are available that can alter the criteria used for routing, these include monitoring the replication lag within the cluster and routing only to slaves that are within a predetermined delay from the current master or using weights to obtain unequal balancing operations. These options may be found in the MariaDB MaxScale Configuration Guide. More detail on the use of maxadmin can be found in the document "MaxAdmin - The MariaDB MaxScale Administration & Monitoring Client Application".
|
||||
MariaDB MaxScale is now ready to start accepting client connections and routing them to the master or slaves within your cluster. Other configuration options are available that can alter the criteria used for routing, these include monitoring the replication lag within the cluster and routing only to slaves that are within a predetermined delay from the current master or using weights to obtain unequal balancing operations. These options may be found in the MariaDB MaxScale Configuration Guide. More details on the use of maxadmin can be found in the document _MaxAdmin - The MariaDB MaxScale Administration & Monitoring Client Application_.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
***This guide was written for lsyncd 2.1.5.***
|
||||
|
||||
This document guides you in setting up multiple MariaDB MaxScale instances and synchronizing the configuration files with lsyncd. Lsyncd is a rsync wrapper which can synchronize files across the network. The lsyncd daemon uses a configuration file to control the files to synchronize and the remote targets where these files are synchronized to.
|
||||
This document guides you in setting up multiple MariaDB MaxScale instances and synchronizing the configuration files with _lsyncd_. Lsyncd is a _rsync_ wrapper which can synchronize files across the network. The lsyncd daemon uses a configuration file to control the files to synchronize and the remote targets where these files are synchronized to.
|
||||
|
||||
Copying the configuration file and running the lsyncd daemon on all the hosts keeps all the configuration files in sync. Modifications in the configuration file on one of the hosts will be copied on the other hosts. This allows administrators to easily provide a highly available, disaster resistant MariaDB MaxScale installation with up-to-date configuration files on all the hosts.
|
||||
|
||||
|
||||
@ -5,9 +5,9 @@ The plugin is capable of returning data in one of two ways, either as MySQL resu
|
||||
|
||||
# Configuration
|
||||
|
||||
The plugin is configured in the maxscale.cnf plugin in much the same way as any other router service is configured, there needs to be a service section in the configuration file and also listeners defined for that service. The service does not however require any backend servers to be associated with it, or any monitors.
|
||||
The plugin is configured in the `maxscale.cnf` configuration file in much the same way as any other router service is configured; there must be a service section in the configuration file and also listeners defined for that service. The service does not however require any backend servers to be associated with it, or any monitors.
|
||||
|
||||
The service entry needs to define the service name, the type as service and the router module to load.
|
||||
The service entry should define the service name, the type as service and the router module to load.
|
||||
The specified user, with the password (plain or encrypted via maxpassword utility) is allowed to connect via MySQL protocol.
|
||||
Currently the user can connect to maxinfo from any remote IP and to localhost as well.
|
||||
|
||||
@ -196,7 +196,7 @@ mysql>
|
||||
|
||||
The show services command does not accept a like clause and will ignore any like clause that is given.
|
||||
|
||||
## Show listeners
|
||||
## Show listeners
|
||||
|
||||
The show listeners command will return a set of status information for every listener defined within the MariaDB MaxScale configuration file.
|
||||
|
||||
@ -248,7 +248,7 @@ mysql> show sessions;
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show clients
|
||||
## Show clients
|
||||
|
||||
The show clients command reports a row for every client application connected to MariaDB MaxScale. Like clauses are not available of the show clients command.
|
||||
|
||||
@ -284,7 +284,7 @@ mysql> show servers;
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show modules
|
||||
## Show modules
|
||||
|
||||
The show modules command reports the information on the modules currently loaded into MariaDB MaxScale. This includes the name type and version of each module. It also includes the API version the module has been written against and the current release status of the module.
|
||||
|
||||
@ -309,7 +309,7 @@ mysql> show modules;
|
||||
mysql>
|
||||
```
|
||||
|
||||
## Show monitors
|
||||
## Show monitors
|
||||
|
||||
The show monitors command reports each monitor configured within the system and the state of that monitor.
|
||||
|
||||
@ -376,7 +376,7 @@ Each row represents a time interval, in 100ms increments, with the counts repres
|
||||
|
||||
The simplified JSON interface takes the URL of the request made to maxinfo and maps that to a show command in the above section.
|
||||
|
||||
## Variables
|
||||
## Variables
|
||||
|
||||
The /variables URL will return the MariaDB MaxScale variables, these variables can not be filtered via this interface.
|
||||
|
||||
@ -460,7 +460,7 @@ $ curl http://maxscale.mariadb.com:8003/listeners
|
||||
$
|
||||
```
|
||||
|
||||
## Modules
|
||||
## Modules
|
||||
|
||||
The /modules URI returns data for each plugin that has been loaded into MariaDB MaxScale. The plugin name, type and version are returned as is the version of the plugin API that the plugin was built against and the release status of the plugin.
|
||||
|
||||
@ -479,7 +479,7 @@ $ curl http://maxscale.mariadb.com:8003/modules
|
||||
$
|
||||
```
|
||||
|
||||
## Sessions
|
||||
## Sessions
|
||||
|
||||
The /sessions URI returns a JSON array with an object for each active session within MariaDB MaxScale.
|
||||
|
||||
@ -511,7 +511,7 @@ $ curl http://maxscale.mariadb.com:8003/clients
|
||||
$
|
||||
```
|
||||
|
||||
## Servers
|
||||
## Servers
|
||||
|
||||
The /servers URI is used to retrieve information for each of the servers defined within the MariaDB MaxScale configuration. This information includes the connection count and the current status as monitored by MariaDB MaxScale. The connection count is only those connections made by MariaDB MaxScale to those servers.
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# 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, 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.
|
||||
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 is placed on the master, to serve the binlogs to each slave. 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 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.
|
||||
|
||||
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 need for the slaves to have knowledge of the master, greatly simplifies the process of replacing a failed master within a replication environment.
|
||||
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
|
||||
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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user