Files
MaxScale/server/modules/routing/binlog
Johan Wikman 55dbaa49c0 Logging target must be explicitly defined.
Whether the log-file should be written to the filesystem or to
shared memory must now be explicitly defined when calling
skygw_logmanager_init() (instead of passing that via the argc/argv
construct).

Also, the meaning of '-l' when invoking maxscale has been changed.

Earlier -l [file|shm] specified whether the trace and debug logs
should be written to shared memory (while the error and message
logs always were written to the filesystem) and the _default_
was to write them to shared memory.

Now, with only one file, '-l' has still the same meaning, but it
decides whether the one and only logfile should be written to shared
memory, or the filesystem and the _default_ is to write it to the
filesystem.
2015-11-11 13:47:34 +02:00
..
2015-11-04 14:26:53 +02:00
2014-05-13 16:06:05 +01:00
2014-05-28 23:38:54 +01:00

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.