Проблема резервного копирования большой базы данных MySQL

Ошибка указывает, что у вас не хватает ресурсов на сервере; причина, вероятно, связана с блокировкой: mysqldump неявно блокирует таблицы при чтении их. Если в базе данных много активности, MySQL должен будет сохранить копию старых данных, доступных для транзакции mysqldump; для достаточно больших таблиц это может быть реальной проблемой.

Если вы не слишком заинтересованы в согласованности данных, вы можете использовать --skip-lock-tables (-q на самом деле не работает, он только предотвращает буферизацию вывода. Это может быть полезно, но не решит вашу проблему) и --single-transaction,

У меня была такая же проблема, и я решил, что это переменная open_files_limit для my.cnf

просто обнови свой my.cnf

open_files_limit = 20000

[& запустить снова]

значение должно быть 2 * количество таблиц в вашей БД. Если это не сработает, попробуйте 3* количество таблиц. Если и этого не произойдет, не увеличивайте, так как это не проблема в вашем случае. Ищите решение снова;-)

Попробуйте выполнить следующее: mysqldump --lock-all-table -u ИМЯ ПОЛЬЗОВАТЕЛЯ -p ПАРОЛЬ> BACKUP.sql

Имейте в виду, что если это в прямом эфире, это может остановить работу сайтов.

Действительно, InnoDB Hot Backup - отличный инструмент, но вы можете предпочесть бесплатный инструмент, недавно выпущенный Percona: XtraBackup. Он выполняет оперативное резервное копирование таблиц InnoDB и XtraDB и может создавать полные и инкрементные резервные копии.

Вы можете попробовать администратор mysql, но, похоже, удивительно, что mysqldump выдает такую ​​ошибку.

ошибка 23: не хватает ресурсов при открытии файла '.\USERNAME\wp_1037_links.MYD'

Это больше похоже на проблемы с ОЗУ или жестким диском на вашем сервере. Это виртуальная машина? Проверьте свой жесткий диск quota первый. Может случиться так, что mySQL не хватает места даже при попытке доступа к таблице - в этом случае даже сжатая резервная копия не поможет.

mysqldump -q -u username -ppassword database> file.sql

-q избегает блокировки таблиц во время дампа

Ошибка, с которой вы столкнулись:
shell> perror 23
Код ошибки 23: слишком много открытых файлов в системе
shell>perror 24
Код ошибки 24: слишком много открытых файлов
Больше информации здесь:
forums.mysql.com/read.php?35,7639,7639#msg-7639

Но, как вы, наверное, уже знаете, mysqldump - не единственный способ выполнить резервное копирование mysql, и это не лучший способ.
Я предполагаю, что вы используете Innodb в качестве механизма хранения, поэтому я бы рекомендовал использовать утилиту innodb для "горячего" резервного копирования: ibbackup.
(он также может выполнять резервное копирование для myisam, но не имеет преимуществ перед mysqlhotcopy)
Но для реальной защиты базы данных Mysql вы можете порекомендовать активировать двоичные журналы на сервере MySQL (говорят, что это только снижает производительность на 1%), чтобы вы могли выполнять восстановление на определенный момент времени, как показано здесь: dev.mysql.com/doc/ RefMan/5.0/ ен / точка-в-время-recovery.html.

Если ни одна из вышеуказанных альтернатив не является для вас опцией, почему бы и нет:
1. ВЫБРАТЬ В... OUTFILE
2. учитывая среду вашего провайдера, вы можете делать снимки файловой системы.
3. или (я знаю, что я подталкиваю) Mysql репликации рабов:)
4. при использовании myisam просто очистите таблицы с блокировкой чтения и скопируйте файлы
5. Запросите обновление сервера MySQL до 6.0 (когда он достигнет GA) и выполните резервное копирование следующим образом:
mysql> РЕЗЕРВНАЯ БАЗА ДАННЫХ 'db-name' в 'c: \ backups \ whynotswitchtounix.bkp';
(обратите внимание на подсознательное сообщение:))

Попробуйте использовать gzip для архивирования ваших файлов sql для резервного копирования http://www.gzip.org/

и, возможно, расширение вашей виртуальной памяти...

Заставить владельца связаться с хостинговой компанией для быстрого резервного копирования