Инкрементные резервные копии MySQL с использованием дампов от ведомого устройства (InnoDB и MyISAM) - PullRequest
2 голосов
/ 26 апреля 2011

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

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

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

Мои вопросы следующие:

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

mysqldump - одиночные транзакции --flush-logs --master-data = 2 --all-database> what.sql

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

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

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

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

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) выше в любую позицию, которую я хочу восстановить в

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

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

1 Ответ

0 голосов
/ 18 мая 2011

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

На ведомом устройстве, пожалуйста, установите следующее в /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.

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

Шаг 1) Запустите «SHOW SLAVE STATUS \ G» и перенаправьте его в ShowSlaveStatus.txt

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

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

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

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

...