Стратегия резервного копирования с использованием репликации

Стратегия резервного копирования с использованием репликации

В моей производственной базе данных есть все таблицы MyISAM, которые реплицируются на подчиненный сервер. Когда мне нужно выполнить резервное копирование, я просто останавливаю сервер MySQL на подчиненном сервере, копирую файлы таблиц, а затем снова запускаю сервер. Это хорошо работает уже несколько лет. Однако теперь мне нужно преобразовать несколько таблиц на главном сервере в InnoDB, потому что у меня возникли некоторые проблемы с блокировкой. Я не думаю, что я смогу просто скопировать файлы таблиц на подчиненный сервер. У меня есть несколько вопросов:

  1. Является ли хорошей идеей смешивать таблицы MyISAM и InnoDB в одной базе данных? Таблицы разных типов будут использоваться в объединениях и других операциях.

  2. Мне нужно 2 процесса резервного копирования на подчиненном сервере - один для резервного копирования MyISAM, а другой для таблиц InnoDB? Мне кажется, это беспорядок.

  3. Могу ли я преобразовать таблицы InnoDB в таблицы MyISAM на подчиненном сервере и сохранить существующий процесс резервного копирования? Можно ли реплицировать таблицу InnoDB на главном сервере в ту же таблицу в формате MyISAM на подчиненном сервере?

решение1

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

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

  3. Нет смысла разделять это на две отдельные резервные копии.

Я бы настоятельно не рекомендовал вам менять формат таблицы на подчиненном сервере, особенно если вы используете транзакции. Сохраняя таблицы InnoDB, подчиненный сервер будет правильно обрабатывать транзакции. Изменяя таблицы на MyISAM, вы можете вызвать проблемы, включив частичные транзакции в резервную копию, что, скорее всего, будет плохой новостью, когда вам придется делать восстановление.

Связанный контент