Как вы обычно создаете резервную копию своей базы данных?

Я использую mysql

Как часто вы резервируете свою базу данных?

Как вы обычно делаете резервную копию вашей базы данных?

Экспортировать все данные в формат sql или cvs и сохранить их в папке ??

Если вы хотите делать резервные копии MySQL правильно, без простоев, вам следует скопировать базу данных на запасной сервер. Он не должен быть очень мощным, он просто должен справляться с нагрузкой записи вашей основной базы данных. Вы не должны использовать этот сервер в производстве. Если репликация никогда не идет в ногу, вам нужен более мощный сервер. Вы можете проверить, сравнив файл журнала и положение из вывода

 > SHOW MASTER STATUS\G

на мастера и

 > SHOW SLAVE STATUS\G

на раба. Я думаю, что MySQL5 покажет отставание от SHOW SLAVE STATUS.

Когда вы счастливы, что ваш раб идет в ногу, вы можете сделать резервные копии, выполнив

1. Остановить репликацию SLAVE STOP;на подчиненном
2. Сделайте mysqldump --optна подчиненном сервере.
3. Снова запустите репликацию SLAVE START;на подчиненном

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

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

Пара случайных советов:

• Не поддавайтесь искушению сделать резервное копирование файлов данных mysql на основе файлов. Это больше хлопот, чем стоит, а дампы MySQL более гибкие.
• Остерегайтесь таблиц блокировки mysqldump во время сброса.
• Остерегайтесь несоответствий в дампах, если только вы не заблокируете каждую таблицу во время дампа
• Используйте mysqldump --opt, так как обычно это самый быстрый способ импортировать полученный SQL
• Дамп так часто, как вы можете. Мы сбрасываем ежедневно, потому что у нас 40 ГБ + данных.
• Периодически проверяйте свои дампы на запасном сервере, чтобы убедиться, что они работают.

Я использую сценарий, который используется mysqldumpдля извлечения данных / схемы в файл для каждой базы данных. Данные резервируются обычной резервной копией netbackup на ленту. Очевидно, что вы можете добавить дополнительные колокольчики, но это делает простой дамп.

#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups


STARTTIME=` date +%Y%m%d-%H%M `

#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"

(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find  ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete



echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
        #generate a backup file name based on the data base name
        BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
        echo "Processing database ${DB} into file ${BACKUP_FILE}"
        # dump the database data/schema into the backup file
        mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
        gzip ${BACKUP_FILE}
done

ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >>  ${LOGFILE} 2>&1

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

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

Резервные копии не должны храниться на серверах с данными в случае аппаратного сбоя.

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

Для программного обеспечения вы можете, например, взглянуть на Bacula или Zmanda

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

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

Мы также храним журналы репликации так долго, как только можем позволить себе сэкономить дисковое пространство. Они также весьма полезны в качестве инструмента отладки, так как они точно записывают, кто что изменил и когда.

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

Одним из хитрых приемов резервного копирования является использование таблиц innodb и параметра -single-транзакции для дампа mysql, так что резервная копия не будет блокировать базу данных во время работы.

Я использую Xtrabackup от Percona . это неблокируемое решение для резервного копирования InnoDB / XtraDB

Вся цель резервного копирования состоит в том, чтобы иметь возможность восстановить.

Я бы не стал защищать дамп CSV как решение для резервного копирования; все это даст вам необработанные данные. Есть еще много чего, особенно с базой данных. Описания таблиц, представления, хранимые процедуры, вы называете это. Если у вас их тоже нет, вы не сможете вернуть их успешно. Существует также приложение RDBMS и конфигурации, чтобы рассмотреть. У вас может быть большое количество исправлений, которые вам также нужно будет включить в среду восстановления, чтобы вывести ее на тот же уровень. Возможно, вы используете какую-то специальную конфигурацию, продиктованную требованиями ваших приложений. У вас может даже быть определенный набор настроек ОС, необходимый для оптимальной работы вашей базы данных. Все это также необходимо вернуть, и если у вас нет решения для резервного копирования, способного на это, это приведет к дополнительным задержкам во времени восстановления,

Для резервных копий баз данных (и резервных копий в целом) я всегда предпочел бы использовать «настоящее» программное обеспечение для резервного копирования, которое может обрабатывать все это.

Совсем недавно я управлял серверами MySQL в EC2. Мы создали снимки EBS на 15-минутной работе cron, сохранилось 3-5 снимков.

Когда мы создавали «традиционные» серверы MySQL, мы ежедневно выполняли резервное копирование через MySQl-ZRM. Резервные копии по сути являются mysqldumps, которые отправляются на ленту, в SAN и т. Д., В зависимости от потребностей клиента.

Оба метода могут быть выполнены без остановки базы данных.

Для MySQL я использую automysqlbackup ( http://sourceforge.net/projects/automysqlbackup/ ), поскольку мое программное обеспечение для резервного копирования (Backup Exec) не поддерживает снимки в системах Linux.

Это работает хорошо, но я собираюсь следить за этой веткой для предложений :)

Мы делаем резервные копии дважды в день, а также запускаем резервные копии журналов каждые 10-15 минут.

Преимущество этого метода заключается в том, что вы можете восстановить одну из резервных копий два раза в день, а затем применить файлы журналов не позднее, чем за последние 15 минут. Таким образом, вы минимизируете объем данных, которые вы можете потерять.

Как часто вы делаете резервные копии своих данных, зависит только от вас. Сколько данных вы можете потерять? Если вы можете позволить себе потерять данные за несколько дней, делайте резервное копирование один раз в день. Данные никогда не меняются? Тогда вам нужен только один экземпляр!