The Binlog Server Common Identity
The Binlog Server Common Identity
Learn about tons of parameters that are useful for binlog server identity configuration so that your slave servers, masters, and config options are up to par.
Join the DZone community and get the full member experience.Join For Free
MariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.
The “identity” of the binlog server layer from the slave server’s point of view is something that could be modified in order to provide all slaves such common parameters for all MariaDB MaxScale servers they could replicate from.
This way, slave servers can see the same values for such config options and they will not be able to understand whether the real master has changed after a failure or a new server has been promoted as master, for any reason.
Set of Parameters Useful for Binlog Server Identity Configuration
Some parameters must be configured with different values in each MariaDB MaxScale server:
server-id: As with
uuid, MariaDB MaxScale must have a unique
server-idfor the connection it makes to the master. This parameter provides the value of the
server-idthat MariaDB MaxScale will use when connecting to the master.
uuid: This is used to set the unique
uuidthat the binlog router uses when it connects to the master server. If no explicit value is given for the
uuidin the configuration file, then a
uuidwill be generated.
Let’s see in the details the parameters that could be set for binlog server common identity:
server-idvalue that MariaDB MaxScale should use to report to the slaves that connect to MariaDB MaxScale. This may either be the same as the
server-idof the real master or can be chosen to be different if the slaves need to be aware of the proxy layer. The real master
server-idwill be used if the option is not set.
master_uuid: It is a requirement of replication that each slave have a unique
uuidvalue. The MariaDB MaxScale router will identify itself to the slaves using the
uuidof the real master if this option is not set.
master_version: The MariaDB MaxScale router will identify itself to the slaves using the server version of the real master if this option is not set.
master_hostname: The MariaDB MaxScale router will identify itself to the slaves using the server hostname of the real master if this option is not set.
slave_hostname: MariaDB MaxScale can optionally identify itself to the master using a custom hostname. The specified hostname can be seen in the master server via the
SHOW SLAVE HOSTScommand. The default is not to send any hostname string during registration. This parameter doesn’t affect the identity seen by the slave servers, but it’s useful in order to properly list all MaxScale servers that are replicating from the master.
An example with one master, two MariaDB Maxscale Servers, and many slaves per each proxy:
server_uuid: A, version: 5.6.15
Slaves (1... N):
server_uuid=FFF, Ver: 5.6.18
server_uuid=DDD, Ver: 5.6.19
server_uuid=ABC, Ver: 5.6.17
The MariaDB MaxScale common identity we want to show all slaves is:
Detailed options set in
maxscale.cnf for each MaxScale server:
router_options=server-id=2, uuid=BBB, master_version=5.6.99-common, master_hostname=common_server, master_uuid=xxx-fff-cccc-fff, master_id=1111
router_options=server-id=3, uuid=CCC, master_version=5.6.99-common, master_hostname=common_server, master_uuid=xxx-fff-cccc-fff, master_id=1111
Query results for the common parameters, issued to any MaxScale server on its client port:
MariaDB> select @@server_id; +-------------+ | @@server_id | +-------------+ | 1111 | +-------------+ 1 row in set (0.00 sec) MariaDB> select @@server_uuid; +------------------+ | @@server_uuid | +------------------+ | xxx-fff-cccc-fff | +------------------+ 1 row in set (0.00 sec) MariaDB> select version(); +---------------+ | VERSION() | +---------------+ | 5.6.29-common | +---------------+ 1 row in set (0.00 sec) MariaDB> select @@hostname; +---------------+ | @@hostname | +---------------+ | common_server | +---------------+ 1 row in set (0.00 sec)
Example in the log file of Max1: both master and slave identity are logged.
2016-01-13 11:06:45 notice : BinlogServer: identity seen by the master: server_id: 2, uuid: XYZ, Host: binlog-server-1 2016-01-13 11:06:45 notice : BinlogServer: identity seen by the slaves: server_id: 1111, uuid: XYZ, hostname: common_server, MySQL version: 5.6.17-mxs
We encourage you to download MariaDB MaxScale, test the Binlog Server setup with the Common Identity variables, and share your experience!
We are done for now, but stay tuned! A follow-up blog post will show how to configure MariaDB MaxScale for both replication proxy and query routing applications.
Published at DZone with permission of Massimiliano Pinto , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.