если в таблице, созданой на предыдуших версиях
есть парочка ТЕХТ/БЛОБ, то при копировании на новую 5.6.20
может вылезти вот такая бяка:

InnoDB: The error message was improved for the case where an UPDATE failed because the row included several BLOB values greater than 768 bytes each, causing the size of a row to exceed half the page size. The old message, was misleading; it suggested using BLOBs, when the 768-byte prefix for each BLOB column was the cause of the limit error: Error Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs A workaround for the problem was to create the table with the ROWFORMAT=DYNAMIC or ROWFORMAT=COMPRESSED clause, which is now suggested in the message. (Bug #13453036, Bug #63507)

mysqldump по дефолту не копирует ROW_FORMAT=COMPRESSED,
да и на старых версиях в обычном формате все было ОК.

Сейчас придется ждать ночи чтоб попытатся формат на динамик или компресед
поменять в продакшене (5.6.11)... может быть после этого
дамп загрузится на локальную 5.6.20

т.е. непонятки в прогрессе...

netwindjavajdbc, может сразу bugid скажете ?
а то какбы понимание бага программистами может отличаться и тут гораздо нужнее понять что об этом думают в самом mysql.


это не баг а типа фича!
ситуация примерно такая:

на продакшене 5.6.11 (или 14? ну не суть) и есть парочк атбалиц
в котой 2 или 4 ТЕХТ и МЕДИУМТЕХТ, формат таблицы Анаконда, КОМПАКТ.

Каждый день делается масклдамп без никаких опций и грузится на
локалный сервер 5.6.19 до последнего времени.
Стоит автоапдейт на линуксе и он весело загрузил версию 5.6.20
на выходные.

Бекап перестал грузится с ошибкой из предыдушего поста.
Оракле где-то закрутил гаики и решил в явном виде
НЕ разрешать Анаконде иметь несколько БЛОБов

Промежуточное решение -- если в дамп добавить
к таким таблицам ROW_FORMAT=COMPRESSED
и выставить в my.cnf в явном виде
innodb_file_per_table=1
innodb_file_format=barracuda
innodb_file_format_max=barracuda
(перегрузить сервер)

... бекап прекрасно грузится.

Проблема что лень вставлять в бекап РОВ_ФОРМАТ -- он BZip-ованый 3 гига.

Предпологаемое лечение:

ночью в тихаря пробратся в продакшен и
поменять Анаконда-КОМПАКТ на Баракуда-КОМПРЕСС.

А потом делать mysqldump с опцией -create-option
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_create-options

только с этой опцией мысклдамп перекинет РОУ_ФОРМАТ-КОМПРЕСС
в креат-табле скрипт в бекапе.

...как то так получается...

...кстати о птичках.... возможно это значит что
новая версия не скушает старые архивы
с анакондами и несколькими к/блобами...

ок, победил я эту мельницу...
наверно опытные админы сразу делют правильно:

Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.

As a result of the redo log BLOB write limit introduced for MySQL 5.6, innodb_log_file_size should be set to a value greater than 10 times the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to do so could result in “ Row size too large ” errors. No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data. (Bug #16963396, Bug #19030353, Bug #69477)

Короче надо (например) innodb_log_file_size=500M выставлять на
10 раз самого большого БЛОБа в системе...
Вообшето ЛОНГТЕХТ может 4Гигабайта брать, значит
реду-лог надо на 40Г выставлять?

Ну ладно... пока работает ..и ладно...

netwindjavajdbcок, победил я эту мельницу...
наверно опытные админы сразу делют правильно:

Читают сначала ченджлоги? Разумеется.
Я как раз вчера прочитал, решил, что вы напутали и попросил конкретный bugid.

А самые опытные вообще сидят на 5.1 и ждут когда админы-хипстеры все бесплатно протестируют и напишут обо всех проблемах на форуме)


"админы-хипстеры" -- во! надо запомнить, навсякей.

На заметку админам-ретроградам:

раньше работало, а теперь -- фик:




ERROR 1060 (42S21) at line 13656: Duplicate column name '0.0'

чет я привел неверный пример.

вот примерно так работало,
а теперь ей не нравится два одинаковых нуля
во втором селекте