MaxScale

Files

MassimilianoPinto 4d78aaa3d8 MXS-1266: blr_slave_gtid_request() the file in slave registration request is checked whether it exists or not

MXS-1266:
blr_slave_gtid_request() the file in slave registration request is
checked whether it exists or not and GTID file info could e set instead.

Also addded:

blr_handle_simple_select_stmt(): only mariadb10_gtid_domain is checked
for SELECT @@GLOBAL.gtid_domain_id slave request
blr_start_master_registration(): only router->mariadb10_compat is
checked before sending SELECT @@GLOBAL.gtid_domain_id to master
blr_file_create calls mxs_mkdir_all()

2017-06-12 17:26:37 +02:00

test

Update change date of 2.2

2017-06-01 10:24:20 +03: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-1266: blr_slave_gtid_request() the file in slave registration request is checked whether it exists or not

2017-06-12 17:26:37 +02:00

blr_master.c

MXS-1266: blr_slave_gtid_request() the file in slave registration request is checked whether it exists or not

2017-06-12 17:26:37 +02:00

blr_slave.c

MXS-1266: blr_slave_gtid_request() the file in slave registration request is checked whether it exists or not

2017-06-12 17:26:37 +02:00

blr.c

MXS-1266: Master GTID registration: MASTER_USE_GTID=Slave_pos

2017-06-12 16:19:53 +02:00

blr.h

MXS-1266: Master GTID registration: MASTER_USE_GTID=Slave_pos

2017-06-12 16:19:53 +02:00

CMakeLists.txt

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

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

maxbinlogcheck.c

Update change date of 2.2

2017-06-01 10:24:20 +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.