Изменен max_allowed_packet и все еще появляется ошибка 'Packet Too Large'

8

Я использую mysqldump для создания плоского файла в целях резервного копирования. Я использовал этот файл для воссоздания базы данных на альтернативном сервере. Я запустил процесс импорта через ssh в командной строке и получил несколько Packet too Largeошибок.

Я перезапустил mysql с гораздо большим max_allowed_packet (т.е. 1000M) и все еще получил ошибку. Я даже попытался установить max_allowed_packet в файле импорта, но все равно получил ошибку.

Есть ли способ убедиться, что установлен max_allowed_packet и / или использовать mysqldump, который создаст файл, который не вызывает эту проблему?

Для справки:

несжатый файл mysqldump составляет ~ 2 ГБ

тип базы данных - INNODB

— Патрик
источник

5

Сначала я подумал о том, что фактически контролирует max_allowed_packet . Вот что я нашел:

В соответствии со страницей 99 «Понимание внутренних компонентов MySQL» (ISBN 0-596-00957-7) , здесь приводятся параграфы 1-3, поясняющие это:

Код сетевого взаимодействия MySQL был написан в предположении, что запросы всегда достаточно короткие, и поэтому могут отправляться и обрабатываться сервером в одном фрагменте, который в терминологии MySQL называется пакетом . Сервер выделяет память для временного буфера для хранения пакета и запрашивает достаточно для его полного заполнения. Эта архитектура требует мер предосторожности, чтобы избежать исчерпания памяти на сервере - ограничение размера пакета, которое выполняет эта опция.

Интересующий код в отношении этой опции находится в sql / net_serv.cc . Посмотрите на my_net_read () , затем выполните вызов my_real_read () и обратите особое внимание на net_realloc () .

Эта переменная также ограничивает длину результата многих строковых функций. Смотрите sql / field.cc и sql / intem_strfunc.cc для подробностей.

Учитывая это определение max_allowed_packet, я обнаружил кое-что еще из ServerFault: объединенные innodb_log_file_size и innodb_log_buffer_size должны быть в десять раз больше, чем ваш самый большой объект BLOB, если у вас много больших объектов.

Имея в виду эти две вещи, я бы увеличил innodb_log_file_size в /etc/my.cnf до максимально допустимого размера, 2047M. Это, конечно, требует следующего

service mysql stop
rm -f /var/lib/mysql/ib_logfile*
service mysql start

Это позволит вместить любые большие капли, которые вы можете иметь в своих данных.

— RolandoMySQLDBA
источник

Любопытно, откуда взялись эти 10x - это простое правило или есть код в MySQL, который говорит, что выделяет 10 фиксированных буферов, поэтому вам нужно 10, чтобы убедиться, что 1 из них достаточно большой?

— Гай

Является ли эта книга авторитетной?

— Pacerier

2

MySQL по- max_allowed_packetпрежнему должен находиться в пределах оболочки, которая его запустила - ulimit -aпоказывает ли это data seg sizeнеограниченность?

— Gaius
источник

2

Почему-то max_allowed_packetигнорируется mysqldump- по замыслу ? Фактическое дополнение есть net_buffer_length. Так что вместо этого попробуйте

mysqldump --net_buffer_length=100k -u root -p databasename > dump.sql

— Leopd
источник

Это очень поучительно! Поскольку в отчете об ошибке обсуждается расширенная вставка в связи с этой проблемой, возможно, выполнение --skip-extended-insert может компенсировать некоторые из них, но, несомненно, приведет к созданию большего mysqldump. +1 за то, что вы нашли этот алмаз в необработанном виде, который Oracle оставит умирать !!!

— RolandoMySQLDBA

--skip-extended-insert определенно работает, но в моей базе данных замедление восстановления в 100 раз делает его непригодным для использования.

— Леопд

Простите, мои соболезнования. Возможно, mysqldump создаст CSV-файлы и попытается загрузить их обратно, используя LOAD DATA INFILE и увеличив объем bulk_insert_buffer_size до 1G или 2G. Эй, ты никогда не знаешь !!!

— RolandoMySQLDBA