(Я рассмотрю ваш вопрос со многих сторон. Возможно, вы не поймете, сколько у вас действительно проблем.)
Уточнение . Таким образом, у вас есть строки больше, чем максимально допустимый для max_allowed_packet
, и, следовательно, для mysqldump
?
SELECT . Вы можете даже SELECT
эти строки? Если нет, вы находитесь в еще большем рассоле.
Резервное копирование . Обратитесь к https://dba.stackexchange.com/questions/20/how-can-i-optimize-a-mysqldump-of-a-large-database/2853#2853 для других способов сделать резервную копию. Или https://dba.stackexchange.com/questions/161708/mysql-database-backup/161886#161886
OOM . Сколько у вас оперативной памяти? Я надеюсь, что это по крайней мере 8 ГБ. В противном случае вы угрожаете уничтожить ОЗУ.
Другая настройка . Если вы можете установить ограничение на количество пакетов, имейте в виду, что innodb_log_file_size
должно быть как минимум в 10 раз больше этого размера. (В настоящее время это только 2G.)
Pushback . Вот аргумент, который нужно дать разработчикам ... Если 'vid' ('video'?) Будет предоставлено конечным пользователям через веб-сервер, то все будет проще (и разрешит ограничение в 1 ГБ), сохранив ссылка на видео файл . Затем используйте <img ...>
(или что-то еще), которое будет достигнуто непосредственно для файла. Это будет обходить базу данных, делая вещи быстрее и проще.
Chunking . Однажды я был вынужден хранить огромные вещи - даже больше, чем 4 ГБ. Мое решение состояло в том, чтобы разделить большие данные на блоки размером 50 КБ (произвольно) и получить 2 таблицы - одну с метаинформацией, одну с таким количеством строк, сколько необходимо для хранения всех фрагментов. Грязный код, грязная база данных, глупый дизайн. О, и я столкнулся с некоторыми другими ограничениями. Apache имеет максимальный размер файла.