December 1, 2017

The Binlog Server Common Identity

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 server they could replicate from.

This way the 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 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 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 is 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

    About Massimiliano Pinto

    Massimiliano is a Senior Software Solutions Engineer working mainly on MaxScale. Massimiliano has worked for almost 15 years in Web Companies playing the roles of Technical Leader and Software Engineer. Prior to joining MariaDB he worked at Banzai Group and Matrix S.p.A, big players in the Italy Web Industry. He is still a guy who likes too much the terminal window on his Mac. Apache modules and PHP extensions skills are included as well.

    Read all posts by Massimiliano Pinto