MaxScale

Files

Johan Wikman b36f6faa7e MXS-1754 Reintroduce maxscale::Worker

Worker is now the base class of all workers. It has a message
queue and can be run in a thread of its own, or in the calling
thread. Worker can not be used as such, but a concrete worker
class must be derived from it. Currently there is only one
concrete class RoutingWorker.

There is some overlapping in functionality between Worker and
RoutingWorker, as there is e.g. a need for broadcasting a
message to all routing workers, but not to other workers.

Currently other workers can not be created as the array for
holding the pointers to the workers is exactly as large as
there will be RoutingWorkers. That will be changed so that
the maximum number of threads is hardwired to some ridiculous
value such as 128. That's the first step in the path towards
a situation where the number of worker threads can be changed
at runtime.

2018-04-16 14:53:08 +03:00

test

MXS-1633 Turn off collecting of sqlite3 memstats

2018-01-30 13:58:37 +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

Merge branch '2.1' into 2.2

2018-01-30 16:28:11 +02:00

blr_master.c

MXS-1754 Reintroduce maxscale::Worker

2018-04-16 14:53:08 +03:00

blr_slave.c

MXS-1506: Combine housekeeper task types

2018-04-10 15:29:30 +03:00

blr.c

MXS-1506: Combine housekeeper task types

2018-04-10 15:29:30 +03:00

blr.h

MXS-1506: Combine housekeeper task types

2018-04-10 15:29:30 +03:00

CMakeLists.txt

MXS-1633 Turn off collecting of sqlite3 memstats

2018-01-30 13:58:37 +02:00

maxbinlogcheck.c

Format all source files with Astyle

2017-09-28 07:04:21 +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.