Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Binlog Server Common Identity

DZone's Guide to

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.

· Database Zone ·
Free Resource

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-id for the connection it makes to the master. This parameter provides the value of the server-id that MariaDB MaxScale will use when connecting to the master.
  • uuid: This is used to set the unique uuid that the binlog router uses when it connects to the master server. If no explicit value is given for the uuid in the configuration file, then a uuid will be generated.

Let’s see in the details the parameters that could be set for binlog server common identity:

  • master-id: The server-id value that MariaDB MaxScale should use to report to the slaves that connect to MariaDB MaxScale. This may either be the same as the server-id of 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-id will be used if the option is not set.
  • master_uuid: It is a requirement of replication that each slave have a unique uuid value. The MariaDB MaxScale router will identify itself to the slaves using the uuid of 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 HOSTS command. 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:


2_routers.jpg


Master:

  • server_id=1, server_uuid: A, version: 5.6.15

MariaDB MaxScale:

  • Max_1: server-id=2, uuid=B
  • Max_2: server-id=3, uuid=C

Slaves (1... N):

  • Slave_1: server_id=10, server_uuid=FFF, Ver: 5.6.18
  • Slave_2: server_id=11, server_uuid=DDD, Ver: 5.6.19
  • Slave_3: server_id=12, server_uuid=ABC, Ver: 5.6.17

The MariaDB MaxScale common identity we want to show all slaves is:

  1. master_id: 1111
  2. master_version: 5.6.99-common
  3. master_uuid: xxx-fff-cccc-fff
  4. master_hostname=common_server

Detailed options set in  maxscale.cnf for each MaxScale server:

Max1:

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

Max2:

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

Conclusion

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.

Additional Resources

MariaDB AX is an open source database for modern analytics: distributed, columnar and easy to use.

Topics:
binlog ,mariadb ,database ,tutorial ,database configuration ,server identity

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}