AutoMysqlBackup - lock-tables=false
Вот файл, который Вы ищете. Обратите внимание, что страница, которую Вы связали, сгенерирована от него.
Это - на самом деле часть Бойких (GTK + Библиотека), который является частью проекта GNOME, но используется хостом других проектов программного обеспечения. Вы могли бы хотеть получить контроль мерзавца ради удобства.
Хорошо, не действительно знакомый с тем программным обеспечением, но:
- Это - сценарий оболочки, таким образом, тривиальный (в теории) для редактирования. Конечно, это - ~2200 сценариев оболочки строки.
- Я думаю - таблицы блокировки прибывают из - выбирают, который указан (от очень быстрого взгляда) наверху
parse_configurationфункция. Вы могли добавить--skip-lock-tablesтам. - Это использует mysql утилиты, таким образом, можно также смочь включить его Ваш
.my.cnfнормальным способом.
В целом:
- Вы не используете InnoDB, но используете MyISAM, таким образом, у Вас нет транзакций. Таким образом, Вы не можете использовать
--single-transaction. - Таким образом необходимо заблокировать для обеспечения непротиворечивости. Даже с блокировкой, не гарантируемый (просто более вероятно). Но это так же, поскольку Вам гарантируют в нормальном функционировании. Рассмотрите InnoDB, серьезно (но прочитайте документы, и исследование сначала, и тест, чтобы удостовериться, что он не повредит Ваше приложение).
- При отключении блокировки Вы можете иметь:
- Запустите резервное копирование
- Резервная таблица A.
- Удалите запись из A и также дочернюю запись в B.
- Резервная таблица B.
- Ваше резервное копирование теперь содержит запись в, который указывает на несуществующую запись в B. Другими словами, не последовательный.
- Существуют more-widely-used решения для резервного копирования MySQL. Возможно, необходимо переключиться на одного из них. Его более легкое для нахождения справки с программным обеспечением, которое использует больше людей (и это также имеет тенденцию быть лучше протестированным).
- Можно думать, что у Вас есть резервное копирование, но Вы не делаете, пока Вы на самом деле не сделали успешное восстановление, предпочтительно от чистого металла (недавно отформатированный жесткий диск). Идеально, Вы обычно делаете это и предпочтительно автоматизируете его. Это не характерно для MySQL, он относится ко всем резервным копиям.
Существует решение (помимо переключения на InnoDB): можно выполнить резервное копирование на ведомом сервере. Не имеет значения при блокировке всех таблиц, или SLAVE STOP SQL_THREAD во время резервного копирования, потому что это не будет иметь значения для основного устройства. Это - решение без времени простоя. У Вас должен быть этот сервер так или иначе как теплое / горячее резервирование в случае, если основное устройство перестало работать.
Существует другое решение, которое минимизирует время простоя: Поместите базу данных по объему LVM, сделайте a FLUSH TABLES WITH READ LOCK, возьмите снимок LVM и затем выпустите свою блокировку чтения (разъединение сделает это). Можно затем сделать резервное копирование от снимка. Это, "Я не могу позволить себе другую машину" решение.
Для Innodb вы можете просто добавить CONFIG_mysql_dump_single_transaction = 'yes' в свой файл conf.
Для механизма MyISAM вам нужно будет добавить --skip-add-locks в файл automysqlbackup. найдите функцию parse_configuration и добавьте значение массива, как указано ниже.
Я убедился, что он отлично работает.
Измените
parse_configuration () {
# OPT string for use with mysqldump ( see man mysqldump )
opt=( '--quote-names' '--opt')
на
parse_configuration () {
# OPT string for use with mysqldump ( see man mysqldump )
opt=( '--quote-names' '--opt' '--skip-add-locks' '--skip-add-drop-table')