Bug #92585 please make report_host and report_port settings dynamic

• Submitted: 27 Sep 2018 8:24
• Modified: 28 Sep 2018 6:13
• Reporter: Simon Mudd (OCA)
• Status: Verified
• Category: MySQL Server: Replication
• Severity: S4 (Feature request)
• Version: 8.0.11
• OS: Any
• CPU Architecture: Any
• Tags: dynamic settings, report_host, report_port

[27 Sep 2018 8:24] Simon Mudd

Description:
As usual if you misconfigure a server and want to adjust settings it's convenient to be able to do this without shutting down the server.

Yet another static variable which has bitten me is report_host.

How to repeat:
root@127.0.0.1 [(none)]> set global report_host = 'hello';
ERROR 1238 (HY000): Variable 'report_host' is a read only variable
root@127.0.0.1 [(none)]> select @@version;
+-----------+
| @@version |
+-----------+
| 8.0.11    |
+-----------+
1 row in set (0.00 sec)

root@127.0.0.1 [(none)]>

Suggested fix:
Please make this and report_port dynamic so it can be adjusted without having to restart the server. This setting is used by tooling like orchestrator to identify the location of slaves for topology management.

[27 Sep 2018 8:34] Simon Mudd

For completeness:

root@127.0.0.1 [(none)]> set global report_port = 3306;
ERROR 1238 (HY000): Variable 'report_port' is a read only variable

[27 Sep 2018 9:47] Georgi Kodinov

Thanks for the reasonable feature request.

[28 Sep 2018 6:11] Simon Mudd

Note: I still have a large number of requests for making more variables dynamic.
Having to report them one by one, and then waiting and seeing that nothing happens is quite frustrating as a forced restart to change settings is just a nuisance.

It would be good to perhaps make a more general look for open feature requests of this type to see which of them could be changed as "it does make a difference".  While many of these settings change infrequently, the require to change settings does happen and the work you have to do to avoid applications seeing downtime while re-adjusting configuration settings is noticeable (to us).

The developers may think it does not matter but when you manage a largish group of MySQL servers you eventually bump into this and whatever front-end, load balancing system you are using has to handle servers going away for "some time", or the replacement of one server with another.