MaxScale

History

Johan Wikman a2a38f952a Add [process|thread] [init|finish] functions to modules

The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.

C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.

2017-01-05 14:44:02 +02:00

test

Make directory name equal to the library name

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

binlog_common.c

Make directory name equal to the library name

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

blr_cache.c

Make directory name equal to the library name

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

blr_file.c

Binlog encryption check against openssl 1.0

2017-01-04 15:15:40 +01:00

blr_master.c

MXS-867: Binlog server encryption key has same format as MariaDB key file

2016-12-12 14:01:54 +01:00

blr_slave.c

MXS-867: Binlog server encryption key has same format as MariaDB key file

2016-12-12 14:01:54 +01:00

blr.c

Add [process|thread] [init|finish] functions to modules

2017-01-05 14:44:02 +02:00

blr.h

MXS-867: Binlog server encryption key has same format as MariaDB key file

2016-12-12 14:01:54 +01:00

CMakeLists.txt

Make directory name equal to the library name

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

maxbinlogcheck.c

MXS-867: Binlog server encryption key has same format as MariaDB key file

2016-12-12 14:01:54 +01: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.