MaxScale

Files

Johan Wikman 1f241a5ed1 Rearrange libraries and build files.

This is the first change in an attempt to arrange the linking so that
more errors are detected at link-time.

- All files in server/core but for gateway.c are linked to one shared
  library called maxscale-common.
- The files log_manager/log_manager.cc and utils/skygw_utils.cc are
  built into maxscale-common as well.
- MaxScale itself consists now only of gateway.c and is linked with
  maxscale-common.
- All plugins link with maxscale-common.
- All executables link in addition with {EMBEDDED_LIB}.

After this change, the change (MXS-517) where query_classifier is the
only component that uses ${EMBEDDED_LIB} and the rest mysqlclient can
be made much cleaner.

After a few additional steps, all shared libraries can be linked with
the linker flags "-Wl,-z,defs", which directs the linker to resolve
all symbols. That will require that all shared libraries list all the
libraries they need, but will at the same time ensure that any
missing symbols are detected at link-time and not at run-time.

2016-01-22 23:26:17 +02:00

test

Rearrange libraries and build files.

2016-01-22 23:26:17 +02:00

blr_cache.c

Log variables moved to log_manager.h

2015-11-04 14:26:53 +02:00

blr_file.c

Removed extra brace

2015-12-28 17:56:39 +01:00

blr_master.c

Removed the 16 chars limitation for binlog file name

2016-01-07 14:36:52 +01:00

blr_slave.c

Changed burst_size to long instead of unsigned long

2015-12-30 16:14:51 +01:00

blr.c

Remove file from slave

2015-12-29 09:42:09 +02:00

CMakeLists.txt

Rearrange libraries and build files.

2016-01-22 23:26:17 +02:00

maxbinlogcheck.c

Rename some log concepts

2015-11-26 17:34:53 +02:00

README

Initial binlog prototype

2014-05-13 16:06:05 +01:00

STATUS

Misc fixes for bin log rotate issues

2014-05-28 23:38:54 +01: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.