MaxScale

History

Markus Mäkelä cbc1e864d9 Use RFC 3986 compliant addresses in log messages

When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.

In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.

The details of the standard can be found at the following addresses:

     https://www.ietf.org/rfc/rfc3986.txt

     https://www.rfc-editor.org/std/std66.txt

2017-03-31 14:12:58 +03:00

test

Update license to BSL 1.1

2017-02-14 21:42:28 +02:00

binlog_common.c

Update license to BSL 1.1

2017-02-14 21:42:28 +02:00

blr_cache.c

Update license to BSL 1.1

2017-02-14 21:42:28 +02:00

blr_file.c

MXS-1077: Add missing close

2017-03-01 10:47:20 +02:00

blr_master.c

Use RFC 3986 compliant addresses in log messages

2017-03-31 14:12:58 +03:00

blr_slave.c

Use RFC 3986 compliant addresses in log messages

2017-03-31 14:12:58 +03:00

blr.c

Use RFC 3986 compliant addresses in log messages

2017-03-31 14:12:58 +03:00

blr.h

Update license to BSL 1.1

2017-02-14 21:42:28 +02:00

CMakeLists.txt

Make directory name equal to the library name

2016-12-01 15:23:42 +02:00

maxbinlogcheck.c

Update license to BSL 1.1

2017-02-14 21:42:28 +02:00

README

Make directory name equal to the library name

2016-12-01 15:23:42 +02:00

STATUS

Make directory name equal to the library name

2016-12-01 15:23:42 +02:00

README

The binlog router is not a "normal" MaxScale router, it is not
designed to be used to route client requests to a database in the
usual proxy fashion. Rather it is designed to allow MaxScale to be
used as a relay server in a MySQL replication environment.

In this environment MaxScale sits between a master MySQL server and
a set of slave servers. The slaves servers execute a change master
to the MaxScale server, otehrwise they are configured in exactly
the same way as a normal MySQL slave server.

The master server configuration is unaltered, it simply sees a
single slave server.

MaxScale is configured as usual, with a service definition that
references the binlog router. The major configuration option to
consider is the router_options paramter, in the binlog router this
provides the binlog specific configuration parameters.

uuid=
This is the UUID that MaxScale uses when it connects
to the real master. It will report the master's
UUID to slaves that connect to it.

server-id=
The server-id that MaxScale uses when it connects
to the real master server. Again it will reports
the master's server-id to the slaves that connect
to it.
user=
The user that MaxScale uses to login to the real
master
password=
The password that MaxScale uses to login to the
real master
master-id=
The server-id of the real master. MaxScale should
get this by sending a query, but at the moment it
is in the configuration file for ease of implementation

An example binlog service configuration is shown below:

[Binlog Service]
type=service
router=binlogrouter
servers=master
router_options=uuid=f12fcb7f-b97b-11e3-bc5e-0401152c4c22,server-id=3,user=repl,password=slavepass,master-id=1
user=maxscale
passwd=Mhu87p2D

The servers list for a binlog router service should contain just
the master server. In future a list will be given and the monitor
used to determine which server is the current master server.