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?