Поиск по сайту:

Инкрементное резервное копирование MySQL — резервное копирование и восстановление баз данных InnoDB и MyIsam на определенный момент времени

На этой странице

  1. Механизм
  2. Требования
  3. Установка
    1. Обновите файл my.cnf:
    2. Запустить automysqlbackup
    3. Запустить mysql-incremental
    4. Редактировать корневой crontab

    1. Временное решение указанной проблемы
    2. Файлы журналов

    Выполнение инкрементных резервных копий является важным требованием для больших производственных баз данных. Без безопасного инкрементного резервного копирования вы не можете сказать себе, что у вас есть надежная производственная база данных. Потому что у вас должно быть достаточно данных, чтобы восстановить вашу базу данных в экстренных случаях. После некоторого поиска в Интернете я не смог найти ни одного инструмента, который может выполнять полное инкрементное резервное копирование для MyISAM и InnodB в смешанной среде, если приложения используют оба механизма базы данных одновременно (возможно, я не являюсь экспертом в поиске в Google и Интернете). Поэтому я решил написать этот, но, чтобы не тратить время и воспользоваться другими решениями с открытым исходным кодом, я предпочел добавить эту функцию в сценарий -automysqlbackup-, который является лучшим сценарием для полного резервного копирования по простоте и широкому использованию.

    Механизм

    Мы используем функцию post- и pre automysqlbackup для создания инкрементной резервной копии. Перед запуском полного резервного копирования mysql-backup-pre выполняет запрос на блокировку всей базы данных во время процесса резервного копирования, потому что нам нужно заморозить двоичный журнал, чтобы избежать каких-либо изменений во время резервного копирования. Имя и положение binlog не могут измениться во время резервного копирования. Позиция двоичного журнала очень важна в последующем процессе инкрементного резервного копирования и будет использоваться в качестве отправной точки для начала следующего инкрементного резервного копирования. После завершения полного резервного копирования mysql-backup-post снимает блокировку базы данных.

    Запрос блокировки: FLUSH TABLES WITH READ LOCK; ВЫБЕРИТЕ СОН(86400)

    Найдите запросы блокировки: mysql -u [имя пользователя] -p [пароль] -e \показать список процессов\ | grep \ВЫБЕРИТЕ СОН (86400)\ | awk {распечатать $1}

    Требования

    • привилегии root для установки пакета и обновления mysql.conf
    • пакет mysql-community-client
    • установка automysqlbackup и mysql-incremental

    Установка

    Установите пакет mysql-community-client для вашего дистрибутива.

    Примечание: после установки MySQL у вас должна быть команда mysqlshow.

    Установите automysqlbackup:

    download the package from https://sourceforge.net/projects/automysqlbackup/
    tar -xzf [PathYouSavedTarFile] -C /tmp/
    cd /tmp/
    ./install.sh

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

    rm /etc/automysqlbackup/myserver.conf

    Установите mysql-incremental: Загрузите пакет с https://sourceforge.net/projects/mysqlincrementalbackup/

    cd /tmp
    wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz
    tar xfz mysql-incremental.tar.gz
    cp mysql-incremental /etc/automysqlbackup/
    chmod 755 /etc/automysqlbackup/mysql-incremental
    cp mysql-backup-post /etc/automysqlbackup/
    chmod 755 /etc/automysqlbackup/mysql-backup-post
    cp mysql-backup-pre /etc/automysqlbackup/
    chmod 755 /etc/automysqlbackup/mysql-backup-pre

    Обновите automysqlbackup.conf:

    Найдите ниже параметры, раскомментируйте и измените их:

            CONFIG_mysql_dump_username='Mysql user name. It must has privileges to get Lock'
	CONFIG_mysql_dump_password='Password'
	CONFIG_backup_dir='The backup directory you want to store full and incremental backup'
	CONFIG_db_names=('databaseName1' 'databaseName2' )
	CONFIG_db_month_names=('databaseName1' 'databaseName2' )
	CONFIG_mysql_dump_master_data=2
	CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
	CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"

    Обновите my.cnf:

    Отредактируйте файл конфигурации MySQL:

    nano /etc/mysql/my.cnf

    1- Формат BinLog

    Из-за некоторых ограничений формата STATEMENT я рекомендую установить формат на основе ROW. Для получения дополнительной информации см. раздел «Устранение неполадок» в этом руководстве. Вы можете проверить тип двоичного формата журнала, выполнив запрос \select @@binlog_format;\. Чтобы изменить формат logbin, вы должны добавить binlog_format=ROW в mysql.conf или my.cnf.

    2- binlog_do_db

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

    binlog_do_db = DATABASENAME1
binlog_do_db = DATABASENAME2

    3- expire_logs_days

    Чтобы двоичные файлы журналов хранились дольше, вы можете увеличить значение этого параметра. Моя рекомендация - 60 дней. Поэтому вы должны добавить или изменить его на \expire_logs_days=60\.

    4- лог-бин

    Каталог, в котором будут храниться двоичные журналы. В старых версиях MySQL mysql-incremenetal мог не найти правильный путь. Поэтому, если вы получите сообщение об ошибке после выполнения mysql-incremental, вы должны обновить сценарий mysql-incremental и указать путь к двоичному журналу.

    5- log_slave_updates

    Если вы настраиваете инкрементное резервное копирование mysql на ведомом сервере, вы должны включить эту опцию. Обычно ведомое устройство не регистрирует обновления в своем собственном двоичном журнале, поскольку они были получены с главного сервера. Эта опция указывает ведомому устройству записывать обновления, выполненные его потоками SQL, в свой собственный двоичный журнал. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates

    Запустите automysqlbackup

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

    automysqlbackup

    После успешного выполнения команды проверьте файл /[BackupDirInAutomysqlbackup]/status/backup_info на наличие новой добавленной информации о ежедневном резервном копировании. Для получения подробной информации об ошибке проверьте /var/log/Backup_Post_Pre_log . Файл резервной копии будет храниться в каталоге /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/ .

    Запустить mysql-инкрементный

    Запустите mysql-incremental вручную сейчас, чтобы иметь по крайней мере одну ежечасную резервную копию.

    mysql-incremental

    В случае ошибки подробности записываются в файл \/var/log/Backup_Incremental_Log\ . Файлы добавочного резервного копирования будут храниться в каталоге /[BackupDirInAutomysqlbackup]/IncrementalBackup/ .

    Отредактируйте корневой crontab

    Вы можете запланировать mysql-incremental более чем на один час. Вы можете найти общее время полного резервного копирования из backup_status, а затем на основе этого значения установить точное время расписания. Конечно, в инкрементном резервном копировании mysql есть механизм, позволяющий находить любое работающее полное резервное копирование перед запуском, поэтому не стоит беспокоиться о конфликте между инкрементным и полным резервным копированием.

    crontab -e
    5 00 * * * root /usr/local/bin/automysqlbackup
25 *  * * * root  /etc/automysqlbackup/mysql-incremental

    Восстановить базу данных

    Для восстановления до определенного момента времени (восстановление на момент времени) сначала необходимо восстановить одну полную ежедневную резервную копию, а затем восстановить последовательно связанные файлы инкрементных резервных копий. Чтобы уточнить, вот шаги по восстановлению базы данных testDB. В примере сценария мы намерены восстановить наши данные до 2015-5-01 в 2 часа ночи. мы установили /backup в качестве нашего основного резервного каталога и testDB в качестве нашей целевой базы данных:

    1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz
2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1
3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2
4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3

    Важные примечания и устранение неполадок

    MySQL поддерживает различные форматы двоичного журнала. Некоторые версии Mysql используют формат бинарного журнала на основе операторов, поэтому у этого типа бинарного журнала есть некоторые ограничения, на которые мы должны обратить пристальное внимание, когда мы намерены использовать его в процедуре добавочного резервного копирования. Когда mysql настроен на формат на основе операторов, он не может правильно фильтровать на основе баз данных. Если вы установите USE или \u для изменения базы данных, а затем обновите другую базу данных, которая не включена в binlog-do-db, в файле binlog будет записано заявление о нежелательном состоянии! и выявит некоторую проблему при восстановлении на основе определенной базы данных, а также если вы перейдете на другую базу данных, не включенную в binlog-do-db, и обновите базу данных, которая включена в binlog-do-db, оператор не будет зарегистрирован в бинлог файл. наша цель добавления баз данных в binlog-do-db - фильтровать на основе базы данных, но это не работает должным образом. Если USE или \u не выполняются перед выполнением запросов, mysqlbinlog не может извлечь запросы на обновление, относящиеся к одной базе данных. Мы объясним больше эту проблему с помощью следующих сценариев:

    databases: 
 - binlog
     - person (table) 
  - binlog2
     - person (table)

 binlog-do-db=binlog2 (it is supposed only change of this database are logged to binlog file)
--------Scenario 1---------
\u binlog2
insert into person (data) values ('17') ---> loged in binlog  *desired state*
insert into binlog.person (data) values ('25'); ---> logged in binlog (target database is 'binlog' ) *undesired state*
--------Scenario 2---------
\u binlog
insert into person (data) values ('17') ---> is not logged in binlog  *desired state*
insert into binlog2.person (data) values ('25'); ---> is not logged in binlog (target database is 'binlog2' ) *undesired state* because the binlog2 database
is begin changed, so we want to have this change,but it will not logged in logbin file
--------Scenario 3---------
if you just connect to database without any USE or \u statement, all of updates on any databases will be logged, but mysqlbinlog can not able to filter
based on specific database, so that is not desirable state for our purpose in incremental backup. Using USE or \u before executing update queries, is very
important. Because mysqlbinlog finds update queries based on USE statement in binlog file.

    Обойти указанную проблему

    1) Путем определения пользователей в базах данных таким образом, что каждый пользователь имеет доступ только к одной базе данных для обновления (пользователь приложения), и при подключении к базе данных необходимо указать имя базы данных. Конечно, у большинства приложений есть конфигурационный файл, в котором задаются учетные данные и имя базы данных, поэтому в этом случае у вас не будет перекрестного доступа к базам данных и не будет проблем с использованием \\USE или\у\.

    2) Если вы используете формат binlog на основе строк, все упомянутые проблемы исчезнут. другими словами, формат на основе строк является более подходящим методом для binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html

    Лог-файлы

    Я попытался записать все в файл журнала, чтобы вы могли найти достаточно информации в журналах:

    /var/log/Backup_Post_Pre_log
    /var/log/Backup_Incremental_Log
    /[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info

    Файл \backup_info\ содержит подробную информацию о резервном копировании и о том, когда резервное копирование закончилось (время указано в формате Unix Time). Он содержит имя бинлога и позицию момента времени начала резервного копирования, тип резервного копирования, количество резервных копий с момента последнего полного резервного копирования и продолжительность резервного копирования.

    Пример резервной_информации:

    1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24
1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1

    Вот описание различных значений:

     1th) 1431043501 : indicates the time when the backup has been finished. You can run date --date @1431043501 command on the server the backup has been done to view it in human readable format.
 2th) Mysql-bin.000026 : indicates the binary log name that backup up to this file has been done.
 3th) 120 : indicates the position of binlog  that backup up to this position in binary log has been done.
 4th) Daily/Hourly: indicates type of backup. Daily does mean the full backup by automysqlbackup script and Hourly is done by mysql-incremental script.
 5th) 2015-05-08: The date that backup has been done. This date will be used in creating directory for incremental backup and also as a base for restore hourly backups. In restoring procedure, first a full backup is restored and then sequentially other incremental backup are restored.
 6th) 0 : indicates number of backups from previous full backup. 0 does mean the backup is full and others mean hourly. This number is very important in restoring procedure.
 7th) 24: The backup duration in second.

    Отчет об ошибке

    Вы можете сообщать об ошибках или оставлять свои предложения и отзывы на странице https://sourceforge.net/projects/mysqlincrementalbackup .