[MXS-705] Maxscale binlog router does not under stand SET NAMES utf8mb4 Created: 2016-05-03  Updated: 2016-05-04  Resolved: 2016-05-04

Status: Closed
Project: MariaDB MaxScale
Component/s: binlogrouter
Affects Version/s: 1.4.3
Fix Version/s: 1.4.3

Type: Bug Priority: Minor
Reporter: Simon Mudd Assignee: Massimiliano Pinto (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 Description   

I notice on maxscale 1.4.3.1-1:

2016-05-03T10:23:06.192082+02:00 host.example.com maxscale[52773]: Unexpected query from 'user'@'10.a.b.c': SET NAMES utf8mb4

The binlog router accepts some other character sets and I am moving to use full unicode support via utf8mb4 but currently this is not understood.

I think that the binlog router does not need to understand the character set really so you probably need to just accept this command and not generate a warning/error like you do for other character sets. If you need to handle the character set then that needs looking at.

This does not seem to be a big deal but does lead to more logging that would be desirable.
In fact probably you should accept any SET NAMES XXXXX command if you don't need to deal with character sets and if you do then handle those you can.

 Comments   
Comment by Simon Mudd [ 2016-05-03 ]

Note: to be clear this is triggered by the configuration on the mysql server:

[user@mysqlhost ~]# grep init /etc/my.cnf
 
init_connect = 'SET NAMES utf8mb4'

Comment by Simon Mudd [ 2016-05-03 ]

So not urgent, nothing "breaks", but given you may see this due to MySQL or MariaDB server configuration it probably should be dealt with in a better fashion.

Comment by Massimiliano Pinto (Inactive) [ 2016-05-03 ]

Added a quick solution:

an else branch replies with OK to SET NAMES XXX (not utf8 or latin1)
...
else

{ free(query_text); return blr_slave_send_ok(router, slave); }

Tested some queries sent to binlog server Mysql interface

MySQL [(none)]> set names 111;
Query OK, 0 rows affected (0.00 sec)

MySQL [(none)]> set names aaaa_utf8mb4_aaaa;
Query OK, 0 rows affected (0.00 sec)

Generated at Thu Feb 08 04:01:19 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.