Как справиться с огромными размерами строк, созданных mysqldump

Я использую mysqldump в задании cron для резервного копирования базы данных с более чем 2 миллионами строк.

Создает текстовый файл, который можно использовать для восстановления каталога данных из командной строки.

Я подумал, что было бы полезно отредактировать дамп перед восстановлением как быстрый способ изменения значений и имен таблиц или столбцов - по крайней мере, пока я не узнаю больше и не буду уверенно делать это с помощью ALTER и UPDATE.

Редактирование больших текстовых файлов меня не беспокоит, но я с удивлением обнаружил, что в дампе 250 мегабайт моей базы данных было всего около 300 строк. Каждая строка была длиной около 800 тыс. Символов.

Есть ли другой способ создания дампов с большим контролем над длиной строки?

Или мне следует обработать дамп с помощью таких инструментов, как sed или Perl?

Ответ 1

По умолчанию mysqldump генерирует только одну команду INSERT для каждой таблицы, в результате получается одна (очень длинная) строка вставленных данных для каждой таблицы, которая была сброшена. Это связано с тем, что "пакетные" вставки намного быстрее, чем если бы он генерировал отдельный запрос INSERT для каждой записи в каждой таблице.

Итак, это не то, что mysqldump создал произвольно длинные строки, и вы можете просто наложить некоторую другую длину отсечки. Линии длинны по какой-то причине.

Если действительно важно, чтобы INSERT разбился на несколько строк, вы можете указать, что с помощью:

mysqldump --extended-insert=FALSE --complete-insert=TRUE ...

Обратите внимание, однако, что восстановление таблиц займет больше времени в этом формате.

Ответ 2

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

Но так или иначе, это вариант, поэтому просто сделайте следующее:

mysqldump --net_buffer_length=5000 ...

Минимальное значение - 4096.

Ответ 3

Я столкнулся с ответом на форумах MySQL, в котором окончательно показано добавление "\n" после того, как каждая группа INSERT невозможна, используя mysqldump самостоятельно, без изменения источника:

Расширенный формат не может быть правильно проанализирован на 100% на основе запятой или скобки, вы должны считать поля. Лучшее решение, исправить mysqldump to linebreak на выходе.

Очень незначительное изменение: в строке 3506 вы можете увидеть, где заканчивается строка запятая выводится:
fputc(',',md_result_file); /* Always row break */

Просто вставьте эту строку сразу после строки 3506:
fputc('\n',md_result_file); /* Lon Binder says wrap that line! */

перекомпилировать и выполнить.

@see http://forums.mysql.com/read.php?28,420002,426110#msg-426110

Спасибо Lon B!

(Я включил контент из форума MySQL на случай, если форум исчезнет.)

Ответ 4

Использование регулярного выражения для разделения строк недостаточно, вам нужен парсер, который будет правильно понимать кавычки и экранирующие символы.

Я просто написал парсер, так как не смог найти его: http://blog.lavoie.sl/2014/06/split-mysqldump-extended-inserts.html

Ответ 5

Этот флаг также работает:

mysqldump --skip-extended-insert

Точно так же, как --extended-insert=FALSE.

Ответ 6

После обработки файла дампа python. Вы можете быть счастливее, чем perl или sed.

Если вы работаете в Linux, вы уже установили его. Если вы работаете в Windows, установщик безболезнен.

До этого, однако, научитесь использовать SQL UPDATE и SQL ALTER. Вы будете счастливы делать все правильно.