MySQL мастер-мастер репликация

By | April 25, 2010

Многие используют в MySQL функцию Master – Slave репликации для зеркалирования или бекапа данных. А что, если slave должен иметь возможность записать данные в БД, которые затем должны реплицироваться на Master? Настройка Master – Master репликации на самом деле не представляет из себя ничего сложного.

Дано:

  • Хост 1 (192.168.1.1) – главный сервер
  • Хост 2 (192.168.1.2) – второй сервер, зеркало первого, который должен реплицировать все с главного, а также передавать ему свои изменения

Необходимо настроить мастер-мастер репликацию между главным сервером и зеркалом. Поехали!

На главном сервере:

  • В файле конфигурации MySQL (my.cnf) отключаем параметр skip-networking и прописываем в bind-address внешний IP данного сервера
  • Туда же добавляем параметры:
  • Перезапускаем сервер и создаем пользователя, для доступа к БД с зеркального сервера:
  • Теперь нужно исключительно точно синхронизировать 2 базы данных, так что для этого сначала блокируем базу данных на запись:

    Запоминаем параметры File и Position и создаём дамп реплицируемых баз:

    Внимание! Блокировка таблиц будет снята, если выйти из консоли MySQL

На зеркальном сервере:

  • Переносим этот дамп на зеркальный сервер и импортируем его:
  • В файле конфигурации MySQL снова отключаем skip-networking и делаем в принципе тоже самое:
  • Перезапускаем mysqld и запускаем процесс репликации в консоли MySQL (используя параметры File и Position с главного сервера):

    Убеждаемся в том, что параметры Slave_IO_Running и Slave_SQL_Running установлены в Yes. На данный момент у нас получилась работающая связка Master – Slave
  • Создаем пользователя, для доступа к БД с главного сервера и записываем показания журнала:

На главном сервере:

  • В открытой ранее консоли MySQL разблокируем ранее блокированные таблицы:
  • Запускаем процесс репликации в консоли MySQL (используя параметры File и Position с зеркала):

    Убеждаемся в том, что параметры Slave_IO_Running и Slave_SQL_Running установлены в Yes.

Обращаю внимание на то, что процесс репликации, а тем более мастер-мастер репликации, очень хрупок и, не смотря на то, что мы позаботились об autoincrement, конфликты все равно будут. Взять хотя бы CMS Drupal – при репликации его БД рано или поздно вылезет ошибка при добавлении записи в таблицу cache с уже существующим, жестко вбитым в запрос, primary key. Чтобы этого избежать, добавьте в my.cnf: