Назад | Перейти на главную страницу

Как отслеживать регулярные резервные копии MySQL.

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

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

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

Итак, на данный момент у меня есть Perl-скрипт, который вызывает mysql-dump и поддерживает его вместе с кодом. Теперь по какой-то причине резервные копии в середине ночи терпят неудачу и создают усеченную версию базы данных. Я разработал это как временное решение, и когда он мне понадобился пару недель назад, резервное копирование не удалось. По этой причине я бы предпочел, чтобы ответственность взял на себя системный администратор, так как у меня есть код, который нужно разработать, и мне не нужно ежедневно проверять выходные данные задания cron.

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

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

Администратор баз данных (и / или системный администратор) получает представление о профиле приложения (сложные транзакции или простые обновления таблиц, окно резервного копирования, размер базы данных, рост данных, количество измененных строк и т. Д.) И выбирают подходящую стратегию резервного копирования для удовлетворения эти требования.

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

Разработчики даже не получают доступа к производственным системам, а даже если и имеют; они не несут ответственности за ежедневное резервное копирование. (Хотя хорошей практикой является создание резервной копии перед выполнением любых работ со структурой базы данных).

Так что я согласен с вами, сделайте это чьей-то проблемой.

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

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

Взгляни на http://dev.mysql.com/doc/refman/5.7/en/backup-methods.html

Простой сценарий, который выполняет резервное копирование всех баз данных на сервере MySQL, каждой базы данных в отдельный файл. Он отправит вам электронное письмо только в случае возникновения проблем. Пока cron работает, резервные копии будут создаваться. Как всегда, проверьте свои возможности восстановления !:

#!/bin/bash

# Simple script to create logical backups of all MySQL databases on
# a server. by http://serverfault.com/users/37681/hbruijn
# Free to use and modify as neeeded.

#======================================================================
# Define paths to system binaries
MYSQL="/usr/bin/mysql"
MYSQLDUMP="/usr/bin/mysqldump"
GZIP="/bin/gzip"
MAIL="/bin/mailx"

# MySQL credentials used for reading the databases.
# either the MySQL DBA account "root"
# or alternatively create a dedicated read-only backup user
# with the following GRANT statement:
# mysql>  GRANT SELECT,RELOAD,SUPER,REPLICATION CLIENT ON *.* TO \
#  backupuser@<this IP or localhost>  identified by 'Very_s3cr3t_passW0rd';
MYHOST="localhost"  # localhost or remote ip-address
MYUSER="backupuser"
MYPASS="Very_s3cr3t_passW0rd"

# Local filesystem or network share to dump back-ups
# Good practice to have file back-ups on their own filesystem
# and not on the root filesystem.
MYBAKDIR="/backups"

# Keep 1 week worth of MySQL backups under $MYBAKDIR
MYDIR=$(date +MySQL/%A)

# Mail errors to somebody in charge
ERROR_RCPT=Herman@example.com

# The rest shouldn't need much tuning
#=====================================================================

errormail(){
cat << EOF | $MAIL -s "MySQL back-up failed !" $ERROR_RCPT
        This is an automatic warning message.

        The MySQL back-up on server: $(hostname) has failed with the following
        errors:

        $1

        Please take appropiate action.

        Thanks in advance.
EOF
exit 1 ;
}

if ! test -d $MYBAKDIR ; then
 mkdir -p $MYBAKDIR || errormail "Backup directory $MYBAKDIR does not exist and could not be created."
fi

if test -d "$MYBAKDIR/$MYDIR" ; then
  rm -rf "$MYBAKDIR/$MYDIR" || errormail "Expired backups from $MYBAKDIR/$MYDIR could not be removed."
fi

mkdir -p "$MYBAKDIR/$MYDIR" || errormail "Todays backup directory $MYBAKDIR/$MYDIR could not be created."

# Generate list with all databases
DATABASES=$(echo "show databases" | $MYSQL -h $MYHOST -u $MYUSER -p$MYPASS |grep -v ^Database$) || errormail "Unable to connect to MySQL database server on $MYHOST please check the supplied credentials"

# Make a logical backup of each database
for DB in $DATABASES
do
  $MYSQLDUMP  -h $MYHOST -u $MYUSER -p$MYPASS --opt --single-transaction $DB > $MYBAKDIR/$MYDIR/$DB.sql  || errormail "Unable to create backup from $DB "
  $GZIP $MYBAKDIR/$MYDIR/$DB.sql  || errormail "Unable to compress $MYBAKDIR/$MYDIR/$DB.sql "

done