Mysql большое резервное копирование базы данных
rewrite ^(.*[^/])$ $1/ permanent; # Capture everything not with a trailing slash and add a trailing slash to it.
При размере данных 5 ГБ вы почти наверняка не можете и не должны использовать дамп (myslqdump, phpmyadmin и т. Д.) В качестве резервной копии. Причина не в резервной копии. Причина в том, что восстановление займет много времени, возможно, много дней в зависимости от структуры таблицы и оборудования вашего сервера. Вам нужно какое-то резервное копирование файлов. Используете ли вы моментальный снимок LVM, Percona XtraBackup, rsync или что-то еще, будет зависеть от используемого механизма хранения, оборудования, файловой системы и ряда других факторов. Это слишком сложный вопрос, чтобы ответить без дополнительных подробностей, но я могу упростить его следующим образом:
- Все, что вы делаете, должно быть ориентировано на восстановление, а не на резервное копирование, поэтому сначала определите RPO (цель точки восстановления) и RTO (целевое время восстановления) и убедитесь, что ваше решение удовлетворяет этим требованиям.
- Если вы используете только InnoDB или в основном InnoDB, за исключением системных таблиц и, возможно, нескольких других небольших и редко обновляемых таблиц, тогда Percona XtraBackup - потенциально хороший вариант.
- В противном случае вам следует рассмотреть возможность создания моментальных снимков файловой системы (LVM).
- Если вы не можете этого сделать, то вам, вероятно, потребуется сделать резервные копии с реплики, и вы можете захотеть сделать это. это в любом случае. Но для начальной настройки реплики требуется резервное копирование, и вам также необходимо регулярно проверять целостность данных реплики (как минимум еженедельно) с помощью контрольной суммы pt-table из Percona Toolkit.
Мы используем Percona XtraBackup. Он будет выполнять неблокирующее резервное копирование больших баз данных. Это достаточно быстро. И оказался очень надежным. Он создает пригодную для использования копию базы данных. Мы делаем резервную копию в отдельный раздел, данные могут быть скопированы оттуда в раздел данных, или мы можем поменять местами разделы, чтобы использовать резервную копию напрямую. И это бесплатно.
Ознакомьтесь с двоичным журналом MySQL . Его можно использовать для настройки инкрементного резервного копирования. Вы также можете использовать mysqldump , но если база данных слишком большая, вероятно, потребуется некоторое время простоя для выполнения полного резервного копирования.
Для больших активных баз данных может оказаться целесообразным создать подчиненное устройство репликации, которое можно отключить для полного резервного копирования.
Резервное копирование может быть выполнено путем остановки репликации и запуска 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
В одной из моих систем есть данные, которые меняются так, что это не имеет смысла. использовать журналы в качестве резервных копий. Размер файла ibdata составляет 131 ГБ. Для этого я использую следующее:
/usr/bin/mysqldump -u $1$MYSQLPASSWORD -f --opt --single-transaction --all-databases | lzma -3
Затем Bacula берет полученный сжатый файл и записывает его в резервную копию системы, как и любой другой файл.
Обратите внимание, что когда вы говорите «размер папки», вы подразумеваете, что вы не используем InnoDB. Это может сделать создание последовательного снимка более сложной задачей.
Некоторые другие распространенные методы включают в себя инкрементальные снимки + бинлог, снимки файловой системы и резервные подчиненные серверы. Существуют также инструменты Percona, которые позволяют читать горячее резервное копирование непосредственно из файла InnoDB.