Як ви можете повторно синхронізувати Master MySQL DB із змінами Slave DB, якщо Master переходить у режим офлайн?

MySQL Server 1 працює як Master.
MySQL Server 2 працює як Slave.

З обома БД в Інтернеті вони перебувають у "ідеальній синхронізації". Якщо Slave не працює в режимі офлайн, немає жодної проблеми, якщо Master все ще в Інтернеті; вони повернуться синхронізуватись, коли Раб знову буде в мережі.

Окрім конфігурації сервера, я перенаправив з'єднання (з кодом JSP) для Slave DB, якщо Master не працює в автономному режимі (я тестував, звичайно, з /etc/init.d/mysqld stop).

Коли Майстер повернеться до Інтернету, чи існує якийсь автоматичний метод синхронізації Майстра з оновленнями Slave?

Один з хороших способів зняти щось подібне - створити реплікацію Master-Master або циркулярну реплікацію. Це не слід плутати з MultiMaster Replciation.

Налаштування кругової реплікації дуже просто, якщо у вас є налаштування Master-Slave Replication. Ось що вам потрібно зробити, щоб налаштувати його.

Для цього прикладу ми припустимо, що реплікація Master-Slave є активною, але у вас виникне невеликий час простою (1-2 хвилини):

Крок 1) Додайте цей рядок до /etc/my.cnf у програмі Master.

log-slave-оновлення

Крок 2) Додайте ці рядки до /etc/my.cnf на підлеглому:

log-bin = mysql-bin (або мати все, що для цього має майстер) log-slave-updates

УВАГА: Ось короткий момент простою !!!

Крок 3) На підлеглому, перезавантажте сервіс mysql

Це активує двійкові журнали на підлеглому

Крок 4) На Майстрі, сервіс mysql stop

Крок 5) Використовуйте rsync, щоб скопіювати папку / var / lib / mysql в підлеглому до ведучого.

ПОПЕРЕДЖЕННЯ: Ось довший момент простою !!!

Крок 6) На Рабі, сервіс mysql зупиниться

Крок 7) На підлеглому дізнайтеся останній бінарний журнал

Крок 8) На підлеглому дізнайтеся розмір файлів останнього бінарного журналу

Крок 9) Використовуйте rsync, щоб скопіювати папку / var / lib / mysql з підлеглого в Master. Це має бути швидша копія.

Крок 10) На Майстрі відредагуйте
рядок 2 master.info з останнім бінарним журналом підлеглого.
Рядок 3 master.info з розміром файлів останнього бінарного журналу підлеглого.
Рядок 4 master.info з IP-адресом підлеглого.
Рядок 5 - це користувач користувача користувача-реплікації (НЕ ТУТУЙТЕСЬ)
Рядок 6 - це пароль користувача реплікації (НЕ ТУЧАЙТЕ)

Крок 11) Видаліть усі бінарні журнали та індексний файл бінарного журналу з головного.

Крок 12) На підлеглому, запустіть службу mysql, зачекайте 15 секунд

Крок 13) На Майстрі запустіть службу mysql

Крок 14) На Майстер запустіть STOP SLAVE; ПОКАЖІТЬ МАЙСТЕР СТАТУС;

Крок 15) На веденому пристрої запустіть ЗМІНИТЕ МАЙСТЕР MASTER_HOST = 'IP Slave', MASTER_USER = 'userid користувача реплікації з Step10', MASTER_PASSWORD = 'пароль користувача реплікації з Step10', MASTER_LOG_FILE = 'двійковий журнал від Step14', MASTER_LOG_POS = LogPos від Step14.

Крок 16) На підлеглому, запустіть START SLAVE;

Крок 17) На Майстер запустіть START SLAVE;

Я робив схожі на це кроки для іншого питання StackExchange, на яке я відповів .

Спробувати !!!

Не з асинхронною реплікацією, яку пропонує MySQL. Ви просто потрапили в прислів’я про те, чому реплікація MySQL "поза коробкою" (до 5.5) сама по собі не є рішенням високої доступності. Робота стає трохи кращою за допомогою 5.5 із напівсинхронною реплікацією (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html), але ціною більш повільного часу транзакції, коли майстер чекає на хід від раба.

Якщо прийняття можливості втрати даних, коли майстер знижується, не є варіантом, я б сказав, що більш досконала настройка, ніж проста майстер / підлеглий, є в порядку.

Багато реплікацій Master to Master вважають більшою проблемою, ніж користю, багато людей, які знамениті MySQL (навіть MySQL AB вже не рекомендує це як рішення високої доступності). Отже, я думаю, що для налаштування DRBD для активації головного та пасивного підлеглого в синхронізації за допомогою копій на рівні блоку саме тут вам потрібно.

ІМХО, Перш за все, у конфігурації, що не є мульти-майстер (ведучий / підлеглий), ваш раб ніколи не повинен приймати записи. Словник my.cnf слід налаштувати і сервер запустити з:

# Flag to not take writes from network
read-only

Далі, щоб вирішити проблему майстра, який не синхронізувався з записуваним підлеглим, який випадково приймає записи, вам доведеться відрізняти дані про обидва хости. Якщо немає ключового зіткнення, ви повинні сприяти своєму колишньому рабовласницькому господареві оволодіти і переобразувати свого старого господаря як раб-хоста, що реплікується з нового господаря. (тут можуть бути / можливо, є проблеми з даними)

Нарешті, якщо цей сценарій відключення / простою навіть є можливим продовженням , знайдіть час, щоб налаштувати обидва хости як мультимайстер (журнал-бін, ідентифікатор сервера, компенсації тощо). Це допоможе вам певною мірою пом'якшити відключення та простої.

Якщо вам потрібно запустити головний / ведений , принаймні отримайте кілька бонусних балів за розділення з'єднань для читання та запису користувачів у своїх ACL та додатках.