MaxScale

Files

Markus Mäkelä 45e0e8bb59 Introduce internal protocol command enum

The enums exposed by the connector are not intended to be used by the
users of the library. The fact that the protocol, and other, modules used
it was in violation of how the library is intended to be used.

Adding an internal mapping into MaxScale also removes some of the
dependencies that the core has on the connector.

2017-09-14 15:30:43 +03:00

test

Minor fixes for testbinlog.c

2017-09-12 14:33:10 +02:00

binlog_common.c

Update change date of 2.2

2017-06-01 10:24:20 +03:00

blr_cache.c

Update change date of 2.2

2017-06-01 10:24:20 +03:00

blr_file.c

MXS-1398: Clean up mysql.h header

2017-09-14 15:30:43 +03:00

blr_master.c

Introduce internal protocol command enum

2017-09-14 15:30:43 +03:00

blr_slave.c

Fix CHANGE MASTER TO with binlog server state BLRM_UNCONFIGURED

2017-09-13 15:51:35 +02:00

blr.c

MXS-1398: Clean up mysql.h header

2017-09-14 15:30:43 +03:00

blr.h

MXS-1398: Clean up mysql.h header

2017-09-14 15:30:43 +03:00

CMakeLists.txt

MXS-1075: Sqlite db for GTID - file, pos mapping

2017-03-28 10:23:09 +02:00

maxbinlogcheck.c

Add support for non-glibc systems

2017-08-02 11:51:55 +03: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.