Резервное копирование большой базы данных mysql

При размере данных 5 ГБ вы почти наверняка не можете и не должны использовать дамп (myslqdump, phpmyadmin и т. Д.) В качестве резервной копии. Причина не в резервной копии. Причина в том, что восстановление займет много времени, возможно, много дней в зависимости от структуры таблицы и оборудования вашего сервера. Вам нужно какое-то резервное копирование файлов. Используете ли вы моментальный снимок LVM, Percona XtraBackup, rsync или что-то еще, будет зависеть от используемого механизма хранения, оборудования, файловой системы и ряда других факторов. Это слишком сложный вопрос, чтобы ответить без дополнительных подробностей, но я могу упростить его следующим образом:

• Все, что вы делаете, должно быть ориентировано на восстановление, а не на резервное копирование, поэтому сначала определите RPO (цель точки восстановления) и RTO (целевое время восстановления) и убедитесь, что ваше решение удовлетворяет этим требованиям.
• Если вы используете только InnoDB или в основном InnoDB, за исключением системных таблиц и, возможно, нескольких других небольших и нечасто обновляемых таблиц, то Percona XtraBackup - потенциально хороший вариант.
• В противном случае вам следует рассмотреть возможность создания снимков файловой системы (LVM).
• Если вы не можете этого сделать, то вам, вероятно, нужно сделать резервную копию с реплики, и вы все равно можете захотеть это сделать. Но настройка реплики для начала требует резервного копирования, и вам также необходимо регулярно проверять целостность данных реплики (как минимум еженедельно) с помощью контрольной суммы pt-table из Percona Toolkit.

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

Затем можно выполнить резервное копирование, остановив репликацию и запустив mysqldump, или остановив mysqld и скопировав физические папки в место для резервных копий. http://www.howtoforge.com/back_up_mysql_dbs_without_interruptions

В любом случае, вероятно, лучше будет сделать это напрямую, а не через phpMyAdmin, поскольку файл дампа будет слишком большим, чтобы ваш браузер мог эффективно обрабатывать его.

Для получения дополнительной информации перейдите сюда, когда mysql.com снова будет в сети http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html

Мы используем Percona XtraBackup. Он будет выполнять неблокирующее резервное копирование больших баз данных. Это достаточно быстро. И оказался очень надежным. Он создает пригодную для использования копию базы данных. Мы делаем резервную копию в отдельный раздел, данные могут быть скопированы оттуда в раздел данных, или мы можем поменять местами разделы, чтобы использовать резервную копию напрямую. И это бесплатно.

Проверять, выписываться Двоичный журнал MySQL. Его можно использовать для настройки инкрементного резервного копирования. Вы также можете использовать mysqldump, но если база данных слишком велика, вероятно, потребуется некоторое время простоя для выполнения полного резервного копирования.

В одной из моих систем есть данные, которые изменяются таким образом, что нет смысла использовать двоичные журналы в качестве резервных копий. Размер файла ibdata составляет 131 ГБ. Для этого я использую следующее:

/usr/bin/mysqldump -u $1$MYSQLPASSWORD -f --opt --single-transaction --all-databases | lzma -3

Затем Bacula берет полученный сжатый файл и записывает его в резервную копию системы, как и любой другой файл.

Обратите внимание: когда вы говорите «размер папки», вы подразумеваете, что не используете InnoDB. Это может усложнить получение последовательного снимка.

Некоторые другие распространенные методы включают в себя моментальные снимки + инкрементальные бинлоги, моментальные снимки файловой системы и резервные подчиненные серверы. Существуют также инструменты Percona, которые позволяют читать горячее резервное копирование непосредственно из файла InnoDB. Какое решение лучше всего подходит для вас, во многом зависит от загрузки системы.