Merge branch '2.1' into develop
This commit is contained in:
Johan Wikman
File diff suppressed because it is too large
Load Diff
@ -24,11 +24,11 @@ module=hintfilter
|
||||
|
||||
## Comments and comment types
|
||||
|
||||
The client connection will need to have comments enabled. For example the `mysql` command line client has comments disabled by default.
|
||||
The client connection will need to have comments enabled. For example the `mysql` command line client has comments disabled by default and they need to be enabled by passing the `-c` option.
|
||||
|
||||
For comment types, use either `-- ` (notice the whitespace) or `#` after the semicolon or `/* .. */` before the semicolon. All comment types work with routing hints.
|
||||
For comment types, use either `-- ` (notice the whitespace after the double hyphen) or `#` after the semicolon or `/* .. */` before the semicolon.
|
||||
|
||||
The MySQL manual doesn`t specify if comment blocks, i.e. `/* .. */`, should contain a w
|
||||
The MySQL manual doesn't specify if comment blocks, i.e. `/* .. */`, should contain a
|
||||
whitespace character before or after the tags, so adding whitespace at both the start and the end is advised.
|
||||
|
||||
## Hint body
|
||||
@ -39,10 +39,10 @@ All hints must start with the `maxscale` tag.
|
||||
-- maxscale <hint body>
|
||||
```
|
||||
|
||||
The hints have two types, ones that route to a server and others that contain
|
||||
The hints have two types, ones that define a server type and others that contain
|
||||
name-value pairs.
|
||||
|
||||
###Routing destination hints
|
||||
### Routing destination hints
|
||||
|
||||
These hints will instruct the router to route a query to a certain type of a server.
|
||||
```
|
||||
|
||||
@ -1,56 +0,0 @@
|
||||
# How errors are handled in MariaDB MaxScale
|
||||
|
||||
This document describes how errors are handled in MariaDB MaxScale, its protocol modules and routers.
|
||||
|
||||
Assume a client, maxscale, and master/slave replication cluster.
|
||||
|
||||
An "error" can be due to failed authentication, routing error (unsupported query type etc.), or backend failure.
|
||||
|
||||
## Authentication error
|
||||
|
||||
Authentication is relatively complex phase in the beginning of session creation. Roughly speaking, client protocol has loaded user information from backend so that it can authenticate client without consulting backend. When client sends authentication data to MariaDB MaxScale data is compared against backend’s user data in the client protocol module. If authentication fails client protocol module refreshes backend data just in case it had became obsolete after last refresh. If authentication still fails after refresh, authentication error occurs.
|
||||
|
||||
Close sequence starts from mysql_client.c:gw_read_client_event where
|
||||
|
||||
1. session state is set to SESSION_STATE_STOPPING
|
||||
|
||||
2. dcb_close is called for client DCB
|
||||
|
||||
1. client DCB is removed from epoll set and state is set to DCB_STATE_NOPOLLING
|
||||
|
||||
2. client protocol’s close is called (gw_client_close)
|
||||
|
||||
* protocol struct is done’d
|
||||
|
||||
* router’s closeSession is called (includes calling dcb_close for backends)
|
||||
|
||||
3. dcb_call_callback is called for client DCB with DCB_REASON_CLOSE
|
||||
|
||||
4. client DCB is set to zombies list
|
||||
|
||||
Each call for dcb_close in closeSession repeat steps 2a-d.
|
||||
|
||||
## Routing errors
|
||||
|
||||
### Invalid capabilities returned by router
|
||||
|
||||
When client protocol module receives query from client the protocol state is (typically) MYSQL_IDLE. The protocol state is checked in mysql_client.c:gw_read_client_event. First place where a hard error may occur is when router capabilities are read. If router response is invalid (other than RCAP_TYPE_PACKET_INPUT and RCAP_TYPE_STMT_INPUT). In case of invalid return value from the router, error is logged, followed by session closing.
|
||||
|
||||
### Backend failure
|
||||
|
||||
When mysql_client.c:gw_read_client_event calls either route_by_statement or directly MXS_SESSION_ROUTE_QUERY script, which calls the routeQuery function of the head session’s router. routeQuery returns 1 if succeed, or 0 in case of error. Success here means that query was routed and reply will be sent to the client while error means that routing failed because of backend (server/servers/service) failure or because of side effect of backend failure.
|
||||
|
||||
In case of backend failure, error is replied to client and handleError is called to resolve backend problem. handleError is called with action ERRACT_NEW_CONNECTION which tells to error handler that it should try to find a replacement for failed backend. Handler will return true if there are enough backend servers for session’s needs. If handler returns false it means that session can’t continue processing further queries and will be closed. Client will be sent an error message and dcb_close is called for client DCB.
|
||||
|
||||
Close sequence is similar to that described above from phase #2 onward.
|
||||
|
||||
Reasons for "backend failure" in rwsplit:
|
||||
|
||||
* router has rses_closed == true because other thread has detected failure and started to close session
|
||||
|
||||
* master has disappeared; demoted to slave, for example
|
||||
|
||||
### Router error
|
||||
|
||||
In cases where MXS_SESSION_ROUTE_QUERY has returned successfully (=1) query may not be successfully processed in backend or even sent to it. It is possible that router fails in routing the particular query but there is no such error which would prevent session from continuing. In this case router handles error silently by creating and adding MySQL error to first available backend’s (incoming) eventqueue where it is found and sent to client (clientReply).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,24 +1,21 @@
|
||||
# Maxbinlogcheck
|
||||
|
||||
# The MySQL/MariaDB binlog check utility
|
||||
|
||||
Massimiliano Pinto
|
||||
|
||||
Last Updated: 07th December 2016
|
||||
# Maxbinlogcheck, the MySQL/MariaDB binlog check utility
|
||||
|
||||
# Overview
|
||||
|
||||
Maxbinlogcheck is a command line utility for checking binlogfiles downloaded by MariaDB MaxScale binlog router or the MySQL/MariaDB binlog files stored in a database server acting as a master in a replication environment.
|
||||
It checks the binlog file against any corruption and incomplete transaction stored and reports a transaction summary after reading all the events.
|
||||
It may optionally truncate binlog file.
|
||||
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
|
||||
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.
|
||||
|
||||
Maxbinlogcheck supports
|
||||
Maxbinlogcheck supports:
|
||||
|
||||
* MariaDB 5.5 and MySQL 5.6
|
||||
|
||||
* MariaDB 10.0 and 10.1 with a command line option
|
||||
|
||||
# Running maxbinlogcheck
|
||||
|
||||
```
|
||||
# /usr/local/bin/maxbinlogcheck /path_to_file/bin.000002
|
||||
```
|
||||
@ -34,29 +31,29 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-f</td>
|
||||
<td>--fix</td>
|
||||
<td>If the option is set the binlog file will be truncated at last safe transaction pos in case of any error</td>
|
||||
<td>-f</td> <td>--fix</td> <td>If set the binlog file will be truncated at
|
||||
last safe transaction pos in case of any error</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-M</td>
|
||||
<td>--mariadb10</td>
|
||||
<td>Check the current binlog against MariaDB 10.0.x events</td>
|
||||
<td>Checks the current binlog against MariaDB 10.0.x events</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-d</td>
|
||||
<td>--debug</td>
|
||||
<td>Set the debug mode. If set the FD Events, Rotate events and opening/closing transactions are displayed.</td>
|
||||
<td>Sets the debug mode. If set the FD Events, Rotate events and
|
||||
opening/closing transactions are displayed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-?</td>
|
||||
<td>--help</td>
|
||||
<td>Print usage information regarding maxbinlogcheck</td>
|
||||
<td>Prints usage information regarding maxbinlogcheck</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-V</td>
|
||||
<td>--version</td>
|
||||
<td>Print the maxbinlogcheck version information</td>
|
||||
<td>Prints the maxbinlogcheck version information</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-K</td>
|
||||
@ -66,12 +63,13 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<tr>
|
||||
<td>-A</td>
|
||||
<td>--aes_algo</td>
|
||||
<td>AES Algorithm for MariaDB 10.1 binlog file decryption (default=AES_CBC, AES_CTR)</td>
|
||||
<td>AES Algorithm for MariaDB 10.1 binlog file decryption (default=AES_CBC,
|
||||
AES_CTR)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-H</td>
|
||||
<td>--header</td>
|
||||
<td>Print the binlog event header</td>
|
||||
<td>Prints the binlog event header</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@ -175,7 +173,7 @@ The maxbinlogcheck command accepts a number of switches
|
||||
This file is corrupted, as reported by the utility:
|
||||
|
||||
```
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002
|
||||
2015-09-08 10:03:16 maxbinlogcheck 1.0.0
|
||||
2015-09-08 10:03:16 Checking /servers/binlogs/new-trx/bin.000002 (bin.000002), size 109498 bytes
|
||||
2015-09-08 10:03:16 Event size error: size 0 at 290.
|
||||
@ -183,7 +181,7 @@ This file is corrupted, as reported by the utility:
|
||||
2015-09-08 10:03:16 Check retcode: 1, Binlog Pos = 245
|
||||
```
|
||||
|
||||
The suggested safe pos is 245
|
||||
The suggested safe pos is 245.
|
||||
|
||||
Use -f option for fix with debug:
|
||||
|
||||
@ -205,7 +203,7 @@ Use -f option for fix with debug:
|
||||
Check it again, last pos will be 245 and no errors will be reported:
|
||||
|
||||
```
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002 -d
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002 -d
|
||||
2015-09-08 09:56:56 maxbinlogcheck 1.0.0
|
||||
2015-09-08 09:56:56 Checking /servers/binlogs/new-trx/bin.000002 (bin.000002), size 245 bytes
|
||||
2015-09-08 09:56:56 - Format Description event FDE @ 4, size 241
|
||||
@ -281,8 +279,10 @@ And finally big transaction is now done.
|
||||
2015-09-08 10:17:16 Check retcode: 0, Binlog Pos = 590760698
|
||||
```
|
||||
|
||||
**Note**
|
||||
with current maxbinlogcheck it's not possible to fix a binlog with incomplete transaction and no other errors
|
||||
**Note**
|
||||
|
||||
With current maxbinlogcheck it's not possible to fix a binlog with incomplete
|
||||
transaction and no other errors
|
||||
|
||||
If that is really desired it will be possible with UNIX command line:
|
||||
|
||||
@ -363,8 +363,8 @@ Check result:
|
||||
Key File content example: /var/binlogs/key_file.txt
|
||||
|
||||
First two bytes are: the encryption scheme, it must be 1, and the ';' separator.
|
||||
Following bytes are the HEX representation of the key (length must be 16, 24 or 32).
|
||||
The example shows a 32 bytes key in HEX format (64 bytes):
|
||||
Following bytes are the HEX representation of the key (length must be 16, 24 or
|
||||
32). The example shows a 32 bytes key in HEX format (64 bytes):
|
||||
|
||||
```
|
||||
1;666f6f62617220676f657320746f207468652062617220666f7220636f66666565
|
||||
|
||||
@ -1,14 +1,13 @@
|
||||
# Module commands
|
||||
|
||||
Introduced in MaxScale 2.1, the module commands are special, module-specific
|
||||
commands. They allow the modules to expand beyond the capabilities of the
|
||||
module API. Currently, only MaxAdmin implements an interface to the module
|
||||
commands.
|
||||
commands. They allow the modules to expand beyond the capabilities of the module
|
||||
API. Currently, only MaxAdmin implements an interface to the module commands.
|
||||
|
||||
All registered module commands can be shown with `maxadmin list commands` and
|
||||
they can be executed with `maxadmin call command <module> <name> ARGS...` where
|
||||
_<module>_ is the name of the module and _<name>_ is the name of the
|
||||
command. _ARGS_ is a command specific list of arguments.
|
||||
_<module>_ is the name of the module and _<name>_ is the name of the command.
|
||||
_ARGS_ is a command specific list of arguments.
|
||||
|
||||
## Developer reference
|
||||
|
||||
@ -16,7 +15,8 @@ The module command API is defined in the _modulecmd.h_ header. It consists of
|
||||
various functions to register and call module commands. Read the function
|
||||
documentation in the header for more details.
|
||||
|
||||
The following example registers the module command _my_command_ for module _my_module_.
|
||||
The following example registers the module command _my_command_ for module
|
||||
_my_module_.
|
||||
|
||||
```
|
||||
#include <maxscale/modulecmd.h>
|
||||
@ -53,9 +53,9 @@ int main(int argc, char **argv)
|
||||
}
|
||||
```
|
||||
|
||||
The array of _modulecmd_arg_type_t_ type is used to tell what kinds of arguments
|
||||
the command expects. The first argument is a SERVER which will be replaced with a
|
||||
pointer to a server. The second argument is an optional string argument.
|
||||
The array _my_args_ of type _modulecmd_arg_type_t_ is used to tell what kinds of
|
||||
arguments the command expects. The first argument is a boolean and the second
|
||||
argument is an optional string.
|
||||
|
||||
Arguments are passed to the parsing function as an array of void pointers. They
|
||||
are interpreted as the types the command expects.
|
||||
|
||||
Reference in New Issue
Block a user