Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
1.2.1
-
None
Description
In server/modules/include/blr.h we have BINLOG_FNAMELEN set to 16. This means that the filestem + extension name for the binary log filename is limited to 16 characters. This works fine while your filestem is short (or the default).
However, if your filestem is the (completely valid) "binary-log", the length of a binary log filename is:
binary-log.0000001 -> 18 characters
|
In a case like this, maxscale does not report any errors, just silently truncates the lognames that are requested from upstream, which then fails, with it being quite unclear as to the source of the problem.
Note that changing the BINLOG_FNAMELEN to a larger value and recompiling is not sufficient to fix the problem, since there is hardcoding of various payload values in blr_make_binlog_dump in blr_master.c that need to be adjusted as well to accomodate longer binlog names (or you just get the binlog filename truncated before sending in blr_make_binlog_dump).
This is a serious issue, since it's not trivial/easy to change the binary log filenames in an existing replication infrastructure without breaking and resetting all the slave relationships.
I'm also concerned that even with changes in blr.h and blr_make_binlog_dump, there could be other places where size assumptions for the binlog filename are hardcoded.