как завершить ежедневный дамп резервной копии mysql без тайм-аутов?

Сбрасывают ли ваши базы данных mysql в общий сетевой (NFS) ресурс? У нас была аналогичная проблема с тайм-аутом, поэтому нам пришлось перезапустить демон mysql со следующими двумя вариантами:

/etc/my.cnf

[mysqld]
net_read_timeout=300
net_write_timeout=300

Пожалуйста, дайте нам знать о ваших последних результатах!

Стиви

логическая резервная копия (mysqldump, например, используемая вашим скриптом) блокирует базу данных. это нарушит работу клиента.

Мой подход к резервному копированию критически важной базы данных заключается в использовании InnoDB на OpenSolaris и ежедневном создании моментальных снимков ZFS каталога данных и каталога журналов.

эти снимки затем копируются на внешний сервер.

поскольку InnoDB является транзакционным, а моментальный снимок является атомарным, нет необходимости выключать сервер перед созданием моментального снимка (восстановление из него аналогично восстановлению после внезапного сбоя питания: InnoDB поддерживает его).

• Если проблема в архивировании. Запустите задание резервного копирования с другого компьютера, подключенного к серверу mysql, и заархивируйте его там.
• вместо дампа с mysql5 вы также можете использовать mysqlhotcopy
• но опять же, мой диск io просто слишком медленный. что это за диски, сколько у вас io ...?

Если вы запускаете файлы данных MySQL на томе LVM, вы можете просто создать моментальный снимок. Взгляни на mylvmbackup для проверенного решения.

Чтобы создать дамп, который вы можете использовать mysql, необходимо заблокировать базу данных, чтобы создать согласованный файл дампа. Я считаю, что это причина тайм-аутов.

Я согласен с другим получать; блокировка, вероятно, является причиной тайм-аутов. Если это так, вы можете создать подчиненное устройство mysql и делать его дампы (желательно на отдельном оборудовании, но что угодно). Это предотвратит блокировку вашего главного db во время дампов, а подчиненное устройство догонит мастер после завершения дампов.

Я использую следующий метод (для Postgres на FreeBSD):

Настройте подчиненный сервер (он у вас есть, на случай, если ваша основная БД загорится, верно?)
Убедитесь, что каталог данных на ведомом устройстве находится в его собственной файловой системе (позже это облегчит жизнь!)

1. Во время резервного копирования остановите подчиненный сервер (репликация останавливается)
2. Сделать снимок файловой системы данных FS (занимает 5-10 секунд)
3. Снова запустить подчиненное устройство (репликация возобновляется)
4. Смонтируйте снимок и сделайте резервную копию его содержимого, как хотите
   • Поскольку это моментальный снимок, он не меняется, и поскольку он был создан при остановке вашей БД, он гарантированно находится в хорошем состоянии покоя.
5. Размонтируйте и удалите снимок.

Это было бы идентично MySQL.

Если ваш сервер / FS не может делать снимки, переместите шаг 3 до конца и пропустите шаги 2 и 5 (репликация остановлена ​​на время резервного копирования, но вам гарантируется последовательное резервное копирование, и, поскольку это подчиненный сервер, ваши клиенты не даже не догадываюсь, что это происходит).

Если все ваши таблицы являются InnoDB, вы можете использовать mysqldump с помощью --single-transaction. Это приведет к сбросу базы данных в согласованном состоянии, в то же время позволяя другим обновлениям ваших таблиц происходить внутри других транзакций. Я перенес несколько систем на InnoDB, чтобы иметь эту функцию.

Если все ваши таблицы являются InnoDB, вы можете использовать --single-transaction. Это заблокирует базу данных только на короткое время, полагаясь на внутренний согласованный моментальный снимок, доступный в транзакции, для завершения резервного копирования.

Если это не так, вам придется заняться чем-нибудь еще; если вы работаете в Linux, вы можете использовать снимок LVM при условии, что вы используете LVM И у вас есть место для одного (вам все равно понадобятся таблицы сброса, пока вы делаете снимок, но снимок выполняется быстро).

Если ваше базовое устройство хранения (например, RAID-контроллер) поддерживает моментальные снимки, вы также можете использовать один из них.

Вы используете InnoDB? Если да, взгляните на инструмент Percona xtrabackup. Или, более конкретно, используйте их скрипт innobackupex, который обертывает xtrabackup и, помимо прочего, добавляет поддержку сброса любых таблиц MyISAM.

Он может выполнять резервное копирование в оперативном режиме (нулевая блокировка для InnoDB), а на выходе - действительный каталог данных mysql, который вы можете скопировать на место для восстановления, обычно делая восстановление намного быстрее, чем восстановление дампа.

Он также поддерживает потоковую передачу резервных копий на другие машины, инкрементные резервные копии и является очень надежным и полезным инструментом.

Я использую его для резервного копирования чрезвычайно загруженных баз данных размером более 500 ГБ без каких-либо проблем и с очень небольшой задержкой репликации, даже когда нагрузка особенно велика.

Вот пример использования, когда создается резервная копия, а затем применяются журналы из резервной копии, чтобы сделать ее пригодной для восстановления:

innobackupex /var/backups/db
innobackupex --apply-log --use-memory=1G /var/backups/db

Восстановление этой резервной копии в ящике будет выглядеть следующим образом (путь к каталогу данных mysql может отличаться в зависимости от дистрибутива):

cp -r /var/backups/db /var/lib/mysql/data
chown -R mysql:mysql /var/lib/mysql/data

Документация Percona для этого инструмента довольно хороша, поэтому вы можете прочитать об этом здесь:

http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html

Что бы вы ни использовали, обязательно протестируйте это, включая часть восстановления!