После переезда с версии MySQL 5.5.13 на 5.6.10 стали вылезать странные грабли.

Симптом №1:

Caused by: java.sql.SQLException: Incorrect string value: '\xE6\xAF\x94FOX...' for column 'parameter_value' at row 4

at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4190)

Симптом №2:

Data truncation: Data too long for column 'channel' at row 1

org.hibernate.exception.DataException: could not execute native bulk manipulation query

Так как "раньше всё работало" и в код приложения никто изменений не вносил, закралось подозрение, что новый mysql работает в каком-то более строгом режиме. Гугление вывело на глобальную переменную sql_mode.

mysql> SHOW global variables LIKE 'sql_mode';

+--------------------------+--------------------------------------------+

| Variable_name | Value |

+--------------------------+--------------------------------------------+

| sql_mode | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |

+--------------------------+--------------------------------------------+

Читаем официальное руководство и видим:

STRICT_TRANS_TABLES

If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement.

На основе этой инфы приходит в голову мысль, что надо этот режим STRICT_TRANS_TABLES попробовать отключить:

mysql> SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';

mysql> SHOW global variables LIKE 'sql_mode';

+---------------+------------------------+

| Variable_name | Value |

+---------------+------------------------+

| sql_mode | NO_ENGINE_SUBSTITUTION |

+---------------+------------------------+

И таки да, после этого запросы, ранее выполнявшиеся с ошибками, стали отрабатывать нормально, как и было на версии 5.5.13. Чтобы сохранить изменения навсегда, в /etc/my.cnf я добавил в секции [mysqld]

sql-mode="NO_ENGINE_SUBSTITUTION"

Однако далее меня ждала еще одна засада – после рестарта mysql-сервера я опять увидел знакомую картину, несмотря на внесенные в /etc/my.cnf изменения:

mysql> show global variables like 'sql_mode';

+--------------------------+--------------------------------------------+

| Variable_name | Value |

+--------------------------+--------------------------------------------+

| sql_mode | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |

+--------------------------+--------------------------------------------+

Это было непостижимо и удивительно. Я уже и еще раз проверил hostname у сервера, дабы убедиться, что всё ранее сделанное происходило именно на том сервере, где и должно было происходить. Почесав пару минут репу, решил проверить наличие других конфигов mysql-сервера в системе. И таки нашёл один такой в /usr/my.cnf:

$ cat /usr/my.cnf | grep -vE "^#" | sed -r "/^$/ d"

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

Вот он, вражеский конфиг, который переопределял моё значение sql_mode! Что самое прикольное, больше ничего в этом конфиге не было. Как будто его специально всунули, чтобы добавить мне головняка. После удаления файла /usr/my.cnf и рестарта mysql-сервера я уже раз и навсегда получил возможность наслаждаться значением sql_mode без STRICT_TRANS_TABLES.