Как справиться с огромными размерами строк, созданных 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. Вы будете счастливы делать все правильно.
