Может ли следующая команда на живом сервере
mysqldump -h XXXX -u root -pXXXXX --skip-opt --flush-privileges
--flush-logs --routines --triggers --allow-keywords
--create-options --add-locks --quick --single-transaction
--extended-insert --all-databases
вызвать зависание веб-приложения (которое полагается на базы данных сервера)?
Некоторые возможности:
Таблицы MyISAM поддерживают только блокировку на уровне таблицы, поэтому пока ваш mysqldump читает таблицу, любые записи будут помещаться в очередь до завершения. Если запись ставится в очередь, любая другая читает затем будет поставлен в очередь после записи, эффективно блокируя приложение. В этом нет ничего особенного mysqldump в этом смысле это всего лишь один SELECT * FROM table это занимает достаточно времени, чтобы запись произошла и попала в очередь.
Таблицы InnoDB поддерживают блокировку на уровне строк, что означает, что операции чтения и записи могут чередоваться, если они не касаются одних и тех же строк. Есть некоторые типы запросов, которые блокируют всю таблицу (например, ALTER table ...) но если бы вы использовали их часто, они бы вызвали проблемы задолго до mysqldump сделал.
А mysqldump также может вызвать гораздо больший доступ к диску, чем обычно. Он эффективно читает всю вашу базу данных и снова записывает ее, возможно, на тот же физический диск. Чтение и запись на один и тот же физический диск вызовут дополнительную задержку (если это не твердотельные накопители), потому что части диска, с которых вы читаете и записываете, должны быть разными, и, следовательно, будет больше поисков, которые требуют времени . Это увеличит среднюю нагрузку на ваш компьютер и замедлит выполнение других операций, требующих доступа к диску.
В большинстве баз данных хранится больше данных, чем у них есть RAM. Ваш mysqldump вполне возможно, очистил кеш файловой системы и заполнил его в основном бесполезными данными, а это означает, что другие запросы доступа к диску должны исходить от реальных дисков (которые в то время имеют избыточную задержку), а не из гораздо более быстрого кеша. Он также мог очистить кеши в MySQL, в зависимости от установленных вами ограничений для каждого из них.
В зависимости от вашей конфигурации MySQL, mysqldump это касается каждой таблицы, возможно, MySQL использует больше RAM, чем у вас есть. Это приведет к тому, что часть вашей активной оперативной памяти будет выгружена на диск, что еще больше увеличит использование диска и окажет огромное влияние на производительность.
Бегать mysqltuner.pl в вашей системе, чтобы помочь настроить вашу конфигурацию и рассмотреть возможность перехода на InnoDB, а не на MyISAM, если вы в настоящее время используете MyISAM. Попробуйте передавать резервные копии прямо на сервер резервного копирования, а не записывать их на тот же диск. (Этого можно добиться разными способами, но это работает: mysqldump [OPTIONS] | gzip | ssh "cat - > database_backup.$(date +%F).sql.gz" <BACKUPHOST>) Если (или когда-то) вы находитесь на InnoDB, вы можете использовать XtraBackup от Percona как лучший инструмент резервного копирования, который примерно так же эффективен, как чистая копия файла, и может использоваться для инициализации репликации. XtraBackup также может транслировать напрямую на другой сервер.