rust_mysql_common icon indicating copy to clipboard operation
rust_mysql_common copied to clipboard

Expose host and port in BinlogRequest builder.

Open darnuria opened this issue 1 year ago • 2 comments

Hello! Thanks for the crate!

The host and port were already exposed but unused in ComRegisterSlave, so I did a little patch to expose them in BinlogRequest, so use them with the async/not async crate.

Linked to https://github.com/blackbeam/mysql_async/pull/250

It's used for reporting in command like

show slave hosts;
+-----------+------------+------+-----------+--------------------------------------+
| Server_id | Host       | Port | Master_id | Slave_UUID                           |
+-----------+------------+------+-----------+--------------------------------------+
| 42        | stage.test | 3306 |      4214 | 88cd28ee-ffff-11ed-b7a8-171e928e6282 |
+-----------+-------------------+-----------+--------------------------------------+

There is also master_heartbeat_period and slave_uuid but they are settable outside of the ComRegisterSlave packet with:

  • slave_uuid, it's settable with set @slave_uuid='88cd28ee-ffff-11ed-b7a8-171e928e6282'"
  • master_heartbeat_period set @master_heartbeat_period=<period in nanosec u64>

These two last are from mysql-internals if you are interested you can checkout how it's done in pymysqlreplication. I didn't included them since they are settable with queries.

I am writing a naive patch for mysql_async. :)

darnuria avatar Jul 20 '23 15:07 darnuria

Hi.

This seem to be unnecessary, because hostname and port is a part of COM_REGISTER_SLAVE rather then COM_BINLOG_DUMP[...] 🤔

blackbeam avatar Aug 14 '23 12:08 blackbeam

Oh, I see the point.

I don't like the idea of putting this unrelated data into the BinlogRequest because, as stated in the docs, it's a COM_BINLOG_DUMP builder. I now see that I shouldn't have exposed BinlogRequest in the mysql_async API.

blackbeam avatar Aug 14 '23 13:08 blackbeam