Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
2.5.18, 6.1.4
-
None
Description
When having a binlog router, or especially multiple ones, in the server list of a monitor, a binlog router may receive a version string from the monitor that already includes the -BinlogRouter postfix, and then append it again, leading to version strings like:
10.5.13-MariaDB-1:10.5.13+maria~focal-log-BinlogRouter-BinlogRouter
|
or in the worst case:
10.5.13-MariaDB-1:10.5.13+maria~focal-log-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-BinlogRouter-Binlog-BinlogRouter
|
Note that the 2nd but last instance just reads Binlog here, so it seems that upon appending the version string is shortened first when exceeding a certain limit, after which -BinlogRouter is appended to it again.
When having just one binlog router as part of the monitored servers I'm seeing -BinlogRouter added twice initially when starting up my test VM setup, but when restarting the maxscale service it goes down to just one, and stays like that.
When having a setup with two maxscale instances providing a binlog router for the same replication setup each, and each maxscale monitoring both its own and the others binlog router instance, restarting a maxscale instance a few times can quickly lead to enough -BinlogRouter postfixes being appended to reach the max. version string length limit.
Proposed fix: either just check whether the version string already ends in -BinlogRouter and do not append it again in that case, or maybe exclude such "special" version strings from what the monitor returns as server version to begin with?