[MXS-2331] Slave server 'server2': response (0xff) differs from master's response (0x00) to COM_QUERY Created: 2019-02-14  Updated: 2019-03-04  Resolved: 2019-03-04

Status: Closed
Project: MariaDB MaxScale
Component/s: readwritesplit
Affects Version/s: 2.3.4
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Dmitry Petrich Assignee: markus makela
Resolution: Duplicate Votes: 0
Labels: galera, replication
Environment:

CentOS Linux release 7.6.1810 (Core)

  1. yum list installed | grep maxscale
    maxscale.x86_64 2.3.4-1 @mariadb-maxscale

Issue Links:
Blocks
is blocked by MXS-1756 Keep session consistent via session v... Closed

 Description   

[Galera Service]
type=service
router=readwritesplit
servers=server1,server2
user=maxscale
passwd=maxscale
enable_root_user=1
use_sql_variables_in=master
#disable_sescmd_history=true
#master_accept_reads=true
#strict_multi_stmt=true

/var/log/messages:
Feb 14 16:07:04 scsmondb18ms maxscale[15836]: (6) Slave server 'server2': response (0xff) differs from master's response (0x00) to COM_QUERY: `use centreon`. Closing slave connection due to inconsistent session state.
Feb 14 16:07:04 scsmondb18ms maxscale[15836]: (6) Router session exceeded session command history limit. Server reconnection is disabled and only servers with consistent session state are used for the duration ofthe session. To disable this warning and the session command history, add `disable_sescmd_history=true` to service 'Galera-Service'. To increase the limit (currently 50), add `max_sescmd_history` to the same service and increase the value.
Feb 14 16:07:09 scsmondb18ms maxscale[15836]: (7) Slave server 'server2': response (0xff) differs from master's response (0x00) to COM_QUERY: `/*!40101 SET character_set_client = @saved_cs_client */;`. Closing slave connection due to inconsistent session state.
Feb 14 16:07:14 scsmondb18ms maxscale[15836]: (10) Slave server 'server2': response (0xff) differs from master's response (0x00) to COM_QUERY: `/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;`. Closing slave connection due to inconsistent session state.

I've remark options:
disable_sescmd_history=true
master_accept_reads=true
strict_multi_stmt=true

Because in this case, error messages just suppressed, but the issue still exists.

I saw closed bug MXS-2079, but it appears again.

 Comments   
Comment by markus makela [ 2019-02-14 ]

This message is most likely caused by the fact that the database hasn't had time to replicate to the server that fails to change the default database:

Feb 14 16:07:04 scsmondb18ms maxscale[15836]: (6) Slave server 'server2': response (0xff) differs from master's response (0x00) to COM_QUERY: `use centreon`. Closing slave connection due to inconsistent session state.

The errors about the SET statements are most likely caused by missing variables. Here's an example of what happens if the variable is not set:

MariaDB [test]> /*!40101 SET character_set_client = @saved_cs_client */;
 
ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'NULL'

This isn't related to MXS-2079 as the queries do not use SELECT ... INTO OUTFILE.

Comment by markus makela [ 2019-02-14 ]

My apologies, I missed the fact that you have use_sql_variables_in=master in your configuration. Try removing that and the commands that failed due to missing user variables should work.

Comment by Dmitry Petrich [ 2019-02-15 ]

In my case use_sql_variables_in=mastert is important:

Feb 15 17:15:15 scsmondb18ms maxscale[15836]: (259) The query can't be routed to all backend servers because it includes SELECT and SQL variable modifications which is not supported. Set use_sql_variables_in=master or split the query to two, where SQL variable modifications are done in the first and the SELECT in the second one.

Comment by markus makela [ 2019-02-18 ]

I'm afraid that this is not a bug but expected behavior in the current version. Once MXS-1756 is implemented it would be possible to avoid this.

Comment by Dmitry Petrich [ 2019-03-04 ]

Thank you, Markus! If so, then the case can be closed for now.

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