Merge branch '2.2' into 2.2-mrm
This commit is contained in:
Markus Mäkelä
@ -11,6 +11,8 @@
|
||||
* Firewall can now prevent the use of functions in conjunction with
|
||||
certain columns.
|
||||
* Parser of MaxScale extended to support window functions and CTEs.
|
||||
* Parser of MaxScale extended to support PL/SQL compatibility features
|
||||
of upcoming 10.3 release.
|
||||
* Prepared statements are now parsed and the execution of read only
|
||||
ones will be routed to slaves.
|
||||
* Server states are persisted, so in case of crash and restart MaxScale
|
||||
@ -20,6 +22,7 @@
|
||||
* The Masking filter can now both obfuscate and partially mask columns.
|
||||
* Binlog router supports MariaDB 10 GTID at both ends.
|
||||
* KILL CONNECTION can now be used through MaxScale.
|
||||
* Environment variables can now be used in the MaxScale configuration file.
|
||||
|
||||
For more details, please refer to:
|
||||
* [MariaDB MaxScale 2.2.0 Release Notes](Release-Notes/MaxScale-2.2.0-Release-Notes.md)
|
||||
|
||||
@ -239,7 +239,7 @@ respect to `SELECT` statements. The allowed values are:
|
||||
statements are cacheable, but must verify that.
|
||||
|
||||
```
|
||||
select=assume_cacheable
|
||||
selects=assume_cacheable
|
||||
```
|
||||
|
||||
Default is `verify_cacheable`. In this case, the `SELECT` statements will be
|
||||
|
||||
@ -570,6 +570,32 @@ This will log all statements that cannot be parsed completely. This may be
|
||||
useful if you suspect that MariaDB MaxScale routes statements to the wrong
|
||||
server (e.g. to a slave instead of to a master).
|
||||
|
||||
#### `substitute_variables`
|
||||
|
||||
Enable or disable the substitution of environment variables in the MaxScale
|
||||
configuration file. If the substitution of variables is enabled and a
|
||||
configuration line like
|
||||
```
|
||||
some_parameter=$SOME_VALUE
|
||||
```
|
||||
is encountered, then `$SOME_VALUE` will be replaced with the actual value
|
||||
of the environment variable `SOME_VALUE`. Note:
|
||||
* Variable substitution will be made _only_ if '$' is the first character
|
||||
of the value.
|
||||
* _Everything_ following '$' is interpreted as the name of the environment
|
||||
variable.
|
||||
* Referring to a non-existing environment variable is a fatal error.
|
||||
|
||||
By default, the value of `substitute_variables` is `false`.
|
||||
```
|
||||
substitute_variables=true
|
||||
```
|
||||
The setting of `substitute_variables` will have an effect on all parameters
|
||||
in the all other sections, irrespective of where the `[maxscale]` section
|
||||
is placed in the configuration file. However, in the `[maxscale]` section,
|
||||
to ensure that substitution will take place, place the
|
||||
`substitute_variables=true` line first.
|
||||
|
||||
### REST API Configuration
|
||||
|
||||
The MaxScale REST API is an HTTP interface that provides JSON format data
|
||||
@ -581,8 +607,7 @@ configuration file.
|
||||
#### `admin_host`
|
||||
|
||||
The network interface where the HTTP admin interface listens on. The default
|
||||
value is the IPv6 address `::` which listens on all available network
|
||||
interfaces.
|
||||
value is the IPv4 address `127.0.0.1` which only listens for local connections.
|
||||
|
||||
#### `admin_port`
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# REST API design document
|
||||
# REST API
|
||||
|
||||
This document describes the version 1 of the MaxScale REST API.
|
||||
|
||||
|
||||
@ -298,6 +298,54 @@ Invalid request body:
|
||||
|
||||
`Status: 403 Forbidden`
|
||||
|
||||
### Update monitor relationships
|
||||
|
||||
```
|
||||
PATCH /v1/monitors/:name/relationships/servers
|
||||
```
|
||||
|
||||
The _:name_ in the URI must map to a monitor name with all whitespace replaced
|
||||
with hyphens.
|
||||
|
||||
The request body must be a JSON object that defines only the _data_ field. The
|
||||
value of the _data_ field must be an array of relationship objects that define
|
||||
the _id_ and _type_ fields of the relationship. This object will replace the
|
||||
existing relationships of the monitor.
|
||||
|
||||
The following is an example request and request body that defines a single
|
||||
server relationship for a monitor.
|
||||
|
||||
```
|
||||
PATCH /v1/monitors/my-monitor/relationships/servers
|
||||
|
||||
{
|
||||
data: [
|
||||
{ "id": "my-server", "type": "servers" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
All relationships for a monitor can be deleted by sending an empty array as the
|
||||
_data_ field value. The following example removes all servers from a monitor.
|
||||
|
||||
```
|
||||
PATCH /v1/monitors/my-monitor/relationships/servers
|
||||
|
||||
{
|
||||
data: []
|
||||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
|
||||
Monitor relationships modified:
|
||||
|
||||
`Status: 204 No Content`
|
||||
|
||||
Invalid JSON body:
|
||||
|
||||
`Status: 403 Forbidden`
|
||||
|
||||
### Destroy a monitor
|
||||
|
||||
Destroy a created monitor. The monitor must not have relationships to any
|
||||
|
||||
@ -467,6 +467,55 @@ Invalid JSON body:
|
||||
|
||||
`Status: 403 Forbidden`
|
||||
|
||||
### Update server relationships
|
||||
|
||||
```
|
||||
PATCH /v1/servers/:name/relationships/:type
|
||||
```
|
||||
|
||||
The _:name_ in the URI must map to a server name with all whitespace replaced
|
||||
with hyphens. The _:type_ in the URI must be either _services_, for service
|
||||
relationships, or _monitors_, for monitor relationships.
|
||||
|
||||
The request body must be a JSON object that defines only the _data_ field. The
|
||||
value of the _data_ field must be an array of relationship objects that define
|
||||
the _id_ and _type_ fields of the relationship. This object will replace the
|
||||
existing relationships of the particular type from the server.
|
||||
|
||||
The following is an example request and request body that defines a single
|
||||
service relationship for a server.
|
||||
|
||||
```
|
||||
PATCH /v1/servers/my-db-server/relationships/services
|
||||
|
||||
{
|
||||
data: [
|
||||
{ "id": "my-rwsplit-service", "type": "services" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
All relationships for a server can be deleted by sending an empty array as the
|
||||
_data_ field value. The following example removes the server from all services.
|
||||
|
||||
```
|
||||
PATCH /v1/servers/my-db-server/relationships/services
|
||||
|
||||
{
|
||||
data: []
|
||||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
|
||||
Server relationships modified:
|
||||
|
||||
`Status: 204 No Content`
|
||||
|
||||
Invalid JSON body:
|
||||
|
||||
`Status: 403 Forbidden`
|
||||
|
||||
### Destroy a server
|
||||
|
||||
```
|
||||
|
||||
@ -420,6 +420,54 @@ Service is modified:
|
||||
|
||||
`Status: 204 No Content`
|
||||
|
||||
### Update service relationships
|
||||
|
||||
```
|
||||
PATCH /v1/services/:name/relationships/servers
|
||||
```
|
||||
|
||||
The _:name_ in the URI must map to a service name with all whitespace replaced
|
||||
with hyphens.
|
||||
|
||||
The request body must be a JSON object that defines only the _data_ field. The
|
||||
value of the _data_ field must be an array of relationship objects that define
|
||||
the _id_ and _type_ fields of the relationship. This object will replace the
|
||||
existing relationships of the service.
|
||||
|
||||
The following is an example request and request body that defines a single
|
||||
server relationship for a service.
|
||||
|
||||
```
|
||||
PATCH /v1/services/my-rw-service/relationships/servers
|
||||
|
||||
{
|
||||
data: [
|
||||
{ "id": "my-server", "type": "servers" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
All relationships for a service can be deleted by sending an empty array as the
|
||||
_data_ field value. The following example removes all servers from a service.
|
||||
|
||||
```
|
||||
PATCH /v1/services/my-rw-service/relationships/servers
|
||||
|
||||
{
|
||||
data: []
|
||||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
|
||||
Service relationships modified:
|
||||
|
||||
`Status: 204 No Content`
|
||||
|
||||
Invalid JSON body:
|
||||
|
||||
`Status: 403 Forbidden`
|
||||
|
||||
### Stop a service
|
||||
|
||||
Stops a started service.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# MariaDB MaxScale 2.1.10 Release Notes
|
||||
# MariaDB MaxScale 2.1.10 Release Notes -- 2017-10-30
|
||||
|
||||
Release 2.1.10 is a GA release.
|
||||
|
||||
@ -40,10 +40,14 @@ To enable this functionality, add `query_retries=<number-of-retries>` under the
|
||||
|
||||
[Here is a list of bugs fixed in MaxScale 2.1.10.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.10)
|
||||
|
||||
* [MXS-1468](https://jira.mariadb.org/browse/MXS-1468) Using dynamic commands to create readwritesplit configs fail after restart
|
||||
* [MXS-1459](https://jira.mariadb.org/browse/MXS-1459) Binlog checksum default value is wrong if a slave connects with checksum = NONE before master registration or master is not accessible at startup
|
||||
* [MXS-1457](https://jira.mariadb.org/browse/MXS-1457) Deleted servers are not ignored when users are loaded
|
||||
* [MXS-1456](https://jira.mariadb.org/browse/MXS-1456) OOM when script variable is empty
|
||||
* [MXS-1451](https://jira.mariadb.org/browse/MXS-1451) Password is not stored with skip_authentication=true
|
||||
* [MXS-1450](https://jira.mariadb.org/browse/MXS-1450) Maxadmin commands with a leading space are silently ignored
|
||||
* [MXS-1449](https://jira.mariadb.org/browse/MXS-1449) Database change not allowed
|
||||
* [MXS-1163](https://jira.mariadb.org/browse/MXS-1163) Log flood using binlog server on Ubuntu Yakkety Yak
|
||||
|
||||
## Packaging
|
||||
|
||||
|
||||
73
Documentation/Release-Notes/MaxScale-2.2.1-Release-Notes.md
Normal file
73
Documentation/Release-Notes/MaxScale-2.2.1-Release-Notes.md
Normal file
@ -0,0 +1,73 @@
|
||||
# MariaDB MaxScale 2.2.1 Release Notes
|
||||
|
||||
Release 2.2.1 is a Beta release.
|
||||
|
||||
This document describes the changes in release 2.2.1, when compared to
|
||||
release 2.2.0.
|
||||
|
||||
For any problems you encounter, please consider submitting a bug
|
||||
report at [Jira](https://jira.mariadb.org).
|
||||
|
||||
## Changed Features
|
||||
### Binlog server
|
||||
|
||||
- MariaDB 10 GTID is always enabled for slave connections.
|
||||
- Automatically set binlog storage to 'tree' mode when
|
||||
_mariadb10_master_gtid_ option is on.
|
||||
|
||||
|
||||
## Dropped Features
|
||||
|
||||
## New Features
|
||||
|
||||
### REST API Relationship Endpoints
|
||||
|
||||
The _servers_, _monitors_ and _services_ types now support direct updating of
|
||||
relationships via the `relationships` endpoints. This conforms to the JSON API
|
||||
specification on updating resource relationships.
|
||||
|
||||
For more information, refer to the REST API documentation. An example of this
|
||||
can be found in the
|
||||
[Server Resource documentation](../REST-API/Resources-Server.md#update-server-relationships).
|
||||
|
||||
### PL/SQL Comaptibility
|
||||
|
||||
The parser of MaxScale has been extended to support the PL/SQL compatibility
|
||||
features of the upcoming 10.3 release. For more information on how to enable
|
||||
this mode, please refer to the
|
||||
[configuration guide](../Getting-Started/Configuration-Guide.md#sql_mode).
|
||||
|
||||
This functionality was available already in MaxScale 2.2.0.
|
||||
|
||||
### Environment Variables in the configuration file
|
||||
|
||||
If the global configuration entry `substitute_variables` is set to true,
|
||||
then if the first character of a value in the configuration file is a `$`
|
||||
then everything following that is interpreted as an environment variable
|
||||
and the configuration value is replaced with the value of the environment
|
||||
variable. For more information please consult the
|
||||
[Configuration Guide](Getting-Started/Configuration-Guide.md).
|
||||
|
||||
## Bug fixes
|
||||
|
||||
[Here is a list of bugs fixed in MaxScale 2.2.1.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.2.1)
|
||||
|
||||
## Known Issues and Limitations
|
||||
|
||||
There are some limitations and known issues within this version of MaxScale.
|
||||
For more information, please refer to the [Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Packaging
|
||||
|
||||
RPM and Debian packages are provided for the Linux distributions supported
|
||||
by MariaDB Enterprise.
|
||||
|
||||
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
|
||||
|
||||
## Source Code
|
||||
|
||||
The source code of MaxScale is tagged at GitHub with a tag, which is identical
|
||||
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
|
||||
is X.Y.Z. Further, *master* always refers to the latest released non-beta version.
|
||||
|
||||
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).
|
||||
@ -159,15 +159,39 @@ the router options.
|
||||
### `mariadb10-compatibility`
|
||||
|
||||
This parameter allows binlogrouter to replicate from a MariaDB 10.0 master
|
||||
server. If `mariadb10_slave_gtid` is not enabled GTID will not be used in the
|
||||
replication. This parameter is enabled by default since MaxScale 2.2.0. In
|
||||
earlier versions the parameter was disabled by default.
|
||||
server: this parameter is enabled by default since MaxScale 2.2.0.
|
||||
In earlier versions the parameter was disabled by default.
|
||||
|
||||
```
|
||||
# Example
|
||||
router_options=mariadb10-compatibility=1
|
||||
```
|
||||
|
||||
|
||||
Additionally, since MaxScale 2.2.1, MariaDB 10.x slave servers
|
||||
can connect to binlog server using GTID value instead of binlog name and position.
|
||||
|
||||
Example of a MariaDB 10.x slave connection to MaxScale
|
||||
|
||||
```
|
||||
MariaDB> SET @@global.gtid_slave_pos='0-10122-230';
|
||||
MariaDB> CHANGE MASTER TO
|
||||
MASTER_HOST='192.168.10.8',
|
||||
MASTER_PORT=5306,
|
||||
MASTER_USE_GTID=Slave_pos;
|
||||
MariaDB> START SLAVE;
|
||||
```
|
||||
|
||||
**Note:**
|
||||
|
||||
- Slave servers can connect either with _file_ and _pos_ or GTID.
|
||||
|
||||
- MaxScale saves all the incoming MariaDB GTIDs (DDLs and DMLs)
|
||||
in a sqlite3 database located in _binlogdir_ (`gtid_maps.db`).
|
||||
When a slave server connects with a GTID request a lookup is made for
|
||||
the value match and following binlog events will be sent.
|
||||
|
||||
|
||||
### `transaction_safety`
|
||||
|
||||
This parameter is used to enable/disable incomplete transactions detection in
|
||||
@ -271,29 +295,6 @@ Example:
|
||||
3;bbbbbbbbbaaaaaaabbbbbccccceeeddddd3333333ddddaaaaffffffeeeeecccd
|
||||
```
|
||||
|
||||
|
||||
### `mariadb10_slave_gtid`
|
||||
If enabled this option allows MariaDB 10.x slave servers to connect to binlog
|
||||
server using GTID value instead of binlog_file name and position.
|
||||
MaxScale saves all the incoming MariaDB GTIDs (DDLs and DMLs)
|
||||
in a sqlite3 database located in _binlogdir_ (`gtid_maps.db`).
|
||||
When a slave server connects with a GTID request a lookup is made for
|
||||
the value match and following binlog events will be sent.
|
||||
Default option value is _off_.
|
||||
|
||||
Example of a MariaDB 10.x slave connection to MaxScale
|
||||
|
||||
```
|
||||
MariaDB> SET @@global.gtid_slave_pos='0-10122-230';
|
||||
MariaDB> CHANGE MASTER TO
|
||||
MASTER_HOST='192.168.10.8',
|
||||
MASTER_PORT=5306,
|
||||
MASTER_USE_GTID=Slave_pos;
|
||||
MariaDB> START SLAVE;
|
||||
```
|
||||
|
||||
**Note:** Slave servers can connect either with _file_ and _pos_ or GTID.
|
||||
|
||||
### `mariadb10_master_gtid`
|
||||
This option allows MaxScale binlog router to register
|
||||
with MariaDB 10.X master using GTID instead of _binlog_file_ name
|
||||
@ -336,22 +337,6 @@ in the binlog files with ignorable events.
|
||||
- It's not possible to specify the GTID _domain_id: the master one
|
||||
is being used for all operations. All slave servers must use the same replication domain as the master server.
|
||||
|
||||
### `binlog_structure`
|
||||
|
||||
This option controls the way binlog file are saved in the _binlogdir_:
|
||||
there are two possible values, `flat | tree`
|
||||
|
||||
The `tree` mode can only be set with `mariadb10_master_gtid=On`
|
||||
|
||||
- `flat` is the default value, files are saved as usual.
|
||||
- `tree` enables the saving of files using this hierarchy model:
|
||||
_binlogdir_/_domain_id_/_server_id_/_filename_
|
||||
|
||||
The _tree_ structure easily allows the changing of the master server
|
||||
without caring about binlog filename and sequence:
|
||||
just change _host_ and _port_, the replication will
|
||||
resume from last GTID MaxScale has seen.
|
||||
|
||||
### `master_retry_count`
|
||||
|
||||
This option sets the maximum number of connection retries when the master server is disconnected or not reachable.
|
||||
@ -390,9 +375,7 @@ follows.
|
||||
encrypt_binlog=1,
|
||||
encryption_algorithm=aes_ctr,
|
||||
encryption_key_file=/var/binlogs/enc_key.txt,
|
||||
mariadb10_slave_gtid=On,
|
||||
mariadb10_master_gtid=Off,
|
||||
binlog_structure=flat,
|
||||
slave_hostname=maxscale-blr-1,
|
||||
master_retry_count=1000,
|
||||
connect_retry=60
|
||||
|
||||
@ -66,9 +66,7 @@ A **complete example** of a service entry for a binlog router service would be a
|
||||
encrypt_binlog=On,
|
||||
encryption_algorithm=aes_ctr,
|
||||
encryption_key_file=/var/binlogs/enc_key.txt,
|
||||
mariadb10_slave_gtid=On,
|
||||
mariadb10_master_gtid=Off,
|
||||
binlog_structure=flat,
|
||||
slave_hostname=maxscale-blr-1,
|
||||
master_retry_count=1000,
|
||||
connect_retry=60
|
||||
@ -199,7 +197,7 @@ If a slave is connected to MaxScale with SSL, an entry will be present in the Sl
|
||||
Slave connected with SSL: Established
|
||||
```
|
||||
|
||||
If option `mariadb10_slave_gtid=On` last seen GTID is shown:
|
||||
If option `mariadb10-compatibility=On` last seen GTID is shown:
|
||||
|
||||
```
|
||||
Last seen MariaDB GTID: 0-10124-282
|
||||
@ -254,7 +252,7 @@ Master_SSL_Verify_Server_Cert: No
|
||||
Master_Info_File: /home/maxscale/binlog/first/binlogs/master.ini
|
||||
```
|
||||
|
||||
If the option `mariadb10_slave_gtid` is set to On, the last seen GTID is shown:
|
||||
If the option `mariadb10-compatibility` is set to On, the last seen GTID is shown:
|
||||
|
||||
```
|
||||
Using_Gtid: No
|
||||
@ -278,14 +276,11 @@ slaves must not use *MASTER_AUTO_POSITION = 1* option.
|
||||
|
||||
It also works with a MariaDB 10.X setup (master and slaves).
|
||||
|
||||
Starting from MaxScale 2.2 the slave connections may include **GTID** feature
|
||||
`MASTER_USE_GTID=Slave_pos` if option *mariadb10_slave_gtid* has been set.
|
||||
|
||||
The default is that a slave connection must not include any GTID
|
||||
feature: `MASTER_USE_GTID=no`
|
||||
Starting from MaxScale 2.2.1 the slave connections might optionally include
|
||||
**GTID** feature `MASTER_USE_GTID=Slave_pos`: only option *mariadb10-compatibility* is required.
|
||||
|
||||
Starting from MaxScale 2.2 it's also possible to register to MariaDB 10.X master using
|
||||
**GTID** using the two new options *mariadb10_master_gtid* and *binlog_structure*.
|
||||
**GTID** using the new option *mariadb10_master_gtid*.
|
||||
|
||||
Current GTID implementation limitations:
|
||||
|
||||
@ -458,19 +453,12 @@ error logs and in *SHOW SLAVE STATUS*,
|
||||
##### MariaDB 10 GTID
|
||||
|
||||
If _mariadb10_master_gtid_ is On changing the master doesn't require the setting of a
|
||||
new _file_ and _pos_, just specify new host and port with CHANGE MASTER; depending on the _binlog_structure_ values some additional steps migth be required.
|
||||
new _file_ and _pos_, just specify new host and port with CHANGE MASTER.
|
||||
|
||||
If _binlog_structure=flat_, in order to keep previous binlog files untouched in MaxScale _binlogdir_ (no overwriting),
|
||||
the next in sequence file must exist in the Master server, as per above scenario _file and pos_ (2).
|
||||
|
||||
It migth also happen that each server in the replication setup has its own binlog file name
|
||||
convention (server1_bin, server2_bin etc) or the user doesn't want to care at all about
|
||||
name and sequence. The _binlog_structure_ option set to _tree_ value simplifies the change
|
||||
master process: as the binlog files are saved using a hierarchy model
|
||||
As the binlog files will be automatically saved using a hierarchy model
|
||||
(_binlogdir/domain_id/server_id/_filename_), MaxScale can work with any filename and any
|
||||
sequence and no binlog file will be overwritten by accident.
|
||||
|
||||
|
||||
**Scenario** example:
|
||||
|
||||
Let's start saying it's a good practice to issue in the new Master `FLUSH TABLES` which
|
||||
@ -508,38 +496,17 @@ MariaDB> SELECT @@global.gtid_current_pos;
|
||||
```
|
||||
|
||||
Starting the replication in MaxScale, `START SLAVE`,
|
||||
will result in new events being downloaded and stored.
|
||||
|
||||
If _binlog_structure=flat_ (default), the binlog events are saved in the new file
|
||||
`mysql-bin.000061`, which should have been created in the Master before starting
|
||||
replication from MaxScale, see above scenario (2)
|
||||
|
||||
If _binlog_structure=tree_, the binlog events are saved in the new file
|
||||
`0/10333/mysql-bin.000001` (which is the current file in the new master)
|
||||
|
||||
The latter example clearly shows that the binlog file has a different sequence number
|
||||
(1 instead of 61) and possibly a new name.
|
||||
will result in new events being downloaded and stored in the new file
|
||||
`0/10333/mysql-bin.000001` (which should be the current file in the new master)
|
||||
|
||||
As usual, check for any error in log files and with
|
||||
|
||||
MariaDB> SHOW SLAVE STATUS;
|
||||
|
||||
Issuing the admin command `SHOW BINARY LOGS` it's possible to see the list
|
||||
of log files which have been downloaded:
|
||||
|
||||
```
|
||||
MariaDB> SHOW BINARY LOGS;
|
||||
+------------------+-----------+
|
||||
| Log_name | File_size |
|
||||
+------------------+-----------+
|
||||
| mysql-bin.000113 | 2214 |
|
||||
...
|
||||
| mysql-bin.000117 | 535 |
|
||||
+------------------+-----------+
|
||||
```
|
||||
|
||||
It's possible to follow the _master change_ history if option `binlog_structure=tree`:
|
||||
the displayed log file names have a prefix with replication domain_id and server_id.
|
||||
of log files which have been downloaded and to follow the _master change_
|
||||
history: the displayed log file names have a prefix with
|
||||
replication domain_id and server_id.
|
||||
|
||||
```
|
||||
MariaDB> SHOW BINARY LOGS;
|
||||
@ -574,8 +541,8 @@ be issued for the new configuration.
|
||||
|
||||
### Removing binary logs from binlogdir
|
||||
|
||||
Since version 2.2, if `mariadb10_slave_gtid` or `mariadb10_master_gtid`
|
||||
are set to On, it's possible to remove the binlog files from _binlogdir_
|
||||
Since version 2.2.1, if `mariadb10-compatibility`is set to On,
|
||||
it's possible to remove the binlog files from _binlogdir_
|
||||
and delete related entries in GTID repository using the admin
|
||||
command `PURGE BINARY LOGS TO 'file'`
|
||||
|
||||
@ -682,8 +649,8 @@ Example:
|
||||
```
|
||||
|
||||
##### MariaDB 10 GTID
|
||||
If connecting slaves are MariaDB 10.x it's also possible to connect with GTID,
|
||||
*mariadb10_slave_gtid=On* has to be set in configuration before starting MaxScale.
|
||||
Since MaxScale 2.2.1 the MariaDB 10.x connecting slaves can optionally connect with GTID,
|
||||
*mariadb10-compatibility=On* has to be set in configuration before starting MaxScale.
|
||||
|
||||
```
|
||||
SET @@global.gtid_slave_pos='';
|
||||
@ -717,7 +684,7 @@ MariaDB> CHANGE MASTER TO
|
||||
MariaDB> START SLAVE;
|
||||
```
|
||||
|
||||
Additionally, if *mariadb10_slave_gtid=On*, it's also possible to retrieve the list of binlog files downloaded from the master with the new admin command _SHOW BINARY LOGS_:
|
||||
Additionally it's also possible to retrieve the list of binlog files downloaded from the master with the new admin command _SHOW BINARY LOGS_:
|
||||
|
||||
```
|
||||
MariaDB> SHOW BINARY LOGS;
|
||||
|
||||
@ -1,115 +1,35 @@
|
||||
.TH maxscale 1
|
||||
.SH NAME
|
||||
maxscale - An intelligent database proxy
|
||||
.SH SYNOPSIS
|
||||
.B maxscale
|
||||
[\fIOPTIONS...\fR]
|
||||
.SH DESCRIPTION
|
||||
MariaDB MaxScale is a database proxy that forwards database statements to one or
|
||||
more database servers.
|
||||
MariaDB MaxScale is an intelligent database proxy that allows the forwarding
|
||||
of database statements to one or more database servers using complex rules, a
|
||||
semantic understanding of the database statements and the roles of the various
|
||||
servers within the backend cluster of databases.
|
||||
|
||||
The forwarding is performed using rules based on the semantic understanding of
|
||||
the database statements and on the roles of the servers within the backend
|
||||
cluster of databases.
|
||||
MariaDB MaxScale is designed to provide load balancing and high availability
|
||||
functionality transparently to the applications. In addition it provides
|
||||
a highly scalable and flexible architecture, with plugin components to
|
||||
support different protocols and routing decisions.
|
||||
|
||||
MariaDB MaxScale is designed to provide, transparently to applications, load
|
||||
balancing and high availability functionality. MariaDB MaxScale has a scalable
|
||||
and flexible architecture, with plugin components to support different protocols
|
||||
and routing approaches.
|
||||
|
||||
.SH OPTIONS
|
||||
.TP
|
||||
.BR "-c, --config-check"
|
||||
Validate configuration file and exit.
|
||||
.TP
|
||||
.BR "-d, --nodaemon"
|
||||
Run MaxScale in the terminal process.
|
||||
.TP
|
||||
.BR -f " \fIFILE\fB, --config=\fIFILE\fR"
|
||||
Relative or absolute pathname of MaxScale configuration file to load.
|
||||
.TP
|
||||
.BR -l "[\fIfile|shm|stdout\fB], --log=[\fIfile|shm|stdout\fB]"
|
||||
Log to file, shared memory or standard output. The default is to log to file.
|
||||
.TP
|
||||
.BR -L " \fIPATH\fB, --logdir=\fIPATH\fB"
|
||||
Path to log file directory.
|
||||
.TP
|
||||
.BR -A " \fIPATH\fB, --cachedir=\fIPATH\fB"
|
||||
Path to cache directory. This is where MaxScale stores cached authentication data.
|
||||
.TP
|
||||
.BR -B " \fIPATH\fB, --libdir=\fIPATH\fB"
|
||||
Path to module directory. Modules are only searched from this folder.
|
||||
.TP
|
||||
.BR -C " \fIPATH\fB, --configdir=\fIPATH\fB"
|
||||
Path to configuration file directory. MaxScale will look for the \fImaxscale.cnf\fR file from this folder.
|
||||
.TP
|
||||
.BR -D " \fIPATH\fB, --datadir=\fIPATH\fB"
|
||||
Path to data directory. This is where the embedded mysql tables are stored in addition to other MaxScale specific data.
|
||||
.TP
|
||||
.BR -E " \fIPATH\fB, --execdir=\fIPATH\fB"
|
||||
Location of the executable files. When internal processes are launched from within MaxScale the binaries are assumed to be in this directory. If you have a custom location for binary executable files you need to add this parameter.
|
||||
.TP
|
||||
.BR -F " \fIPATH\fB, --persistdir=\fIPATH\fB"
|
||||
Location of persisted configuration files. These files are created when configuration is changed during runtime so that the changes may be reapplied at startup.
|
||||
.TP
|
||||
.BR -M " \fIPATH\fB, --module_configdir=\fIPATH\fB"
|
||||
Location of module configuration files.
|
||||
.TP
|
||||
.BR -H " \fIPATH\fB, --connector_plugindir=\fIPATH\fB"
|
||||
Location of MariaDB Connector-C plugin.
|
||||
.TP
|
||||
.BR -N " \fIPATH\fB, --language=\fIPATH\fB"
|
||||
Location of errmsg.sys file.
|
||||
.TP
|
||||
.BR -P " \fIPATH\fB, --piddir=\fIPATH\fB"
|
||||
Location of MaxScale's PID file.
|
||||
.TP
|
||||
.BR -R " \fIPATH\fB, --basedir=\fIPATH\fB"
|
||||
Base path for all other paths.
|
||||
.TP
|
||||
.BR -U " \fIUSER\fB, --user=\fIUSER\fB"
|
||||
Run MaxScale as another user. The user ID and group ID of this user are used to run MaxScale.
|
||||
.TP
|
||||
.BR -s " [\fIyes\fB|\fIno\fB], --syslog=[\fIyes\fB|\fIno\fB]"
|
||||
Log messages to syslog.
|
||||
.TP
|
||||
.BR -S " [\fIyes\fB|\fIno\fB], \fB--maxlog=[\fIyes\fB|\fIno\fB]"
|
||||
Log messages to MaxScale's own log files.
|
||||
.TP
|
||||
.BR -G " [\fIyes\fB|\fIno\fB], \fB--log_augmentation=[\fI0\fB|\fI1\fB]"
|
||||
Augment messages with the name of the function where the message was logged (default: 0)"
|
||||
.TP
|
||||
.BR -g " [\fIyes\fB|\fIno\fB], \fB--debug=[\fIArg1\fB,\fIArg2,...\fB]"
|
||||
Enable or disable debug features. Supported arguments:
|
||||
\fBdisable-module-unloading \fRShared libraries are not unloaded on exit, may give better Valgrind leak reports.
|
||||
\fBenable-module-unloading \fREnable unloading. Default setting.
|
||||
.TP
|
||||
.BR "-v, --version"
|
||||
Print version information and exit.
|
||||
.TP
|
||||
.BR "-V, --version-full"
|
||||
Print full version information including the Git commit the binary was built from and exit.
|
||||
.TP
|
||||
.BR "-?, --help"
|
||||
Show the help information for MaxScale and exit.
|
||||
.SH EXAMPLES
|
||||
Tutorials on GitHub:
|
||||
Quickstart Guide:
|
||||
|
||||
.RS
|
||||
.I https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Documentation-Contents.md#tutorials
|
||||
.I https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-setting-up-mariadb-maxscale/
|
||||
.RE
|
||||
.SH SEE ALSO
|
||||
The MariaDB MaxScale documentation on the MariaDB Knowledge Base:
|
||||
|
||||
Installation Guide:
|
||||
|
||||
.RS
|
||||
.I https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale/
|
||||
.I https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-mariadb-maxscale-installation-guide/
|
||||
.RE
|
||||
|
||||
The MariaDB MaxScale documentation on GitHub:
|
||||
MaxScale Documentation:
|
||||
|
||||
.RS
|
||||
.I https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Documentation-Contents.md
|
||||
.I https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-contents/
|
||||
.RE
|
||||
|
||||
.SH BUGS
|
||||
You can see a list of known bugs and report new bugs at:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user