Details
Minor
Description
With row-level binlogs enabled, the following command can produce ambiguously escaped output:
$ mysqlbinlog -v --base64-output=DECODE-ROWS master-bin.000001
To reproduce the issue, I can run the following SQL command (table schema not relevant):
INSERT INTO `mytest`.`tbl` VALUES ('\n test \\x0a');
This results in the mysqlbinlog output:
### INSERT INTO `mytest`.`tbl` ### SET ### @1='\x0a test \x0a'
As you can see, it is impossible to differentiate the output of a new-line character (0x0A) from the un-escaped string "\x0a".
Gliffy Diagrams
Attachments
Issue Links
- links to
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Pushed into 5.5 tree
The effect is reproducible on MySQL as well (at least 5.6, but I suppose on previous versions too).
However, I don't see any problems with replication as such, the events seem to be replicated correctly, so it's just visual representation that's ambiguous.
You might want to file a bug report or feature request at bugs.mysql.com.