Блог

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

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

Однако на моем сервере есть таблицы MyISAM и InnoDB, и, похоже, есть противоречивые предложения о том, как выполнять полное резервное копирование в каждом случае. Если бы это был строго InnoDB, я мог бы выполнить mysqldump с помощью —single-transaction , но этот параметр предупреждает меня, что MyISAM все еще может быть изменен.

Мои вопросы заключаются в следующем:

(1) Обоснованно ли то, что в руководстве MySQL предлагается резервное копирование:

mysqldump —single-transaction —flush-logs —master-data=2 —all-databases > whatever.sql

… было бы неподходящим, поскольку таблицы MyISAM могут измениться (таблицы не заблокированы с помощью —single-transaction), поэтому запускается новый файл журнала, но он может содержать запросы к таблицам MyISAM, которые фактически уже были запущены на сервере до того, как эти таблицы попали в дамп (и инкрементное восстановление попытается повторно выполнить эти запросы, когда они не понадобятся)?

(2) Является ли единственным способом получить «правильную» полную резервную копию с таблицами MyISAM и InnoDB, используя —lock-all tables? (Или в этот момент просто выключите сервер / скопируйте файлы, поскольку все равно все заблокировано)

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

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

http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html#option_mysqldump_master-data

На самом деле эти инструкции предназначены для настройки ведомого устройства вне ведомого устройства, но мне интересно, правдоподобно ли следующее?

Раз в день:

1. Остановите подчиненное устройство
2. Показать статус подчиненного устройства и получить главный файл журнала и позицию
3. Сделайте полный дамп подчиненного устройства, пока в него не вносятся изменения (MyISAM или InnoDB)
4. Запустите подчиненное устройство снова
5. Переместите мой полный дамп на главный сервер в какой-нибудь каталог резервных копий

В случае восстановления:

1. Восстановить полный дамп из (5) выше
2. Запустите восстановление на момент времени, используя позиции отсюда http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery-positions.html чтобы перейти из позиции в (2) выше в любую позицию, которую я хочу восстановить, в

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

Спасибо за любую помощь!

Ваш план «раз в день» очень правдоподобен по одной простой причине: вы сначала остановили подчиненное устройство. Никаких новых транзакций поступать не будет. Я хотел бы предложить кое-что дополнительное.

На подчиненном устройстве, пожалуйста, установите следующее в /etc/my.cnf

 [mysqld]
innodb_max_dirty_pages_pct=0
  

Вот почему:

Пока подчиненное устройство обрабатывает mysqldump, если в пуле буферов innodb какие-либо таблицы содержат «грязные» страницы, страницы должны быть сброшены на диск. Я заметил, что в вашем mysqldump вы уже используете эту опцию. По умолчанию значение innodb_max_dirty_pages_pct равно 90. Все существующие грязные страницы должны быть записаны на диск. Если innodb_max_dirty_pages_pct все время равен нулю, очистка буферного пула innodb выполняется быстрее.

Вы можете настроить это динамически, не перезапуская mysql. Просто запустите это:

 SET GLOBAL innodb_max_dirty_pages_pct = 0;
  

Это сохранит пул буферов innodb скудным и средним.

Я также вижу, что в вашей команде mysqldump есть —master-data=2. Это сработает, только если на подчиненном устройстве включены двоичные журналы. Если нет, вам нужно получить основной журнал и положение с главного устройства, потому что mysqldump не может этого сделать. Вот как вы можете получить файл журнала главного устройства и его местоположение с подчиненного устройства:

Шаг 1) Запустите «ПОКАЗАТЬ СОСТОЯНИЕ ПОДЧИНЕННОГО устройства G» и перенаправьте на ShowSlaveStatus.txt

Шаг 2) Получите следующую информацию из ShowSlaveStatus.txt
Relay_Master_Log_File
Exec_Master_Log_Pos

Шаг 3) Запишите эти два значения в конце файла дампа.

Еще одна вещь:

Пожалуйста, добавьте —routines —triggers в команду mysqldump. Вы никогда не знаете, когда вы можете решить написать хранимые процедуры и триггеры. Кроме того, нет необходимости в —lock-tables, если подчиненное устройство остановлено.