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) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:8.0.11 OS:Any
Assigned to: 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.