Реплікація MySQL на географічно окремих серверах

Моя організація розглядала, як географічно поширити наші сервери, зберігаючи резервні копії дуже актуальними та ідеально розподіляючи навантаження.

Початкова річ, яку я маю на увазі, - це Rails на MySQL. Частота запису не надто висока (статті / коментарі залишаються менше ніж 1 хвилину, хоча деякі з них мають великі медіа-додатки).

Тому,

• чи добре працює реплікація MySQL у широких мережах?
• Чи означає, що з'єднання (або підлеглий сервер) знижується, означає, що потрібно вручну втручання (як тільки два сервери можуть знову поговорити один з одним) або відновлення автоматично?
• Якщо господар зникає, що потрібно, щоб перетворити раба в пана? Чи є стандартні сценарії / інструменти, які допомагають це впоратися?
• Будь-які інші gotchas тощо?

Ми використовуємо реплікацію в центрах обробки даних у кількох європейських країнах (тому вони не перебувають у світі один від одного, але вони, звичайно, не локальні), і це працює без проблем.

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

Якщо у вас є два сервери, і майстер зникає, тоді, щоб перетворити підлеглого на «головний», просто зупиніть реплікацію та змініть свій код (щоб записати на новий «master»). Якщо у вас є три або більше серверів, і майстер зникає, то зупиніть реплікацію на рабах, змініть їх на використання нового ведучого і почніть знову. Якщо вони точно не синхронізовані (залежить від того, скільки передається даних, наскільки зайняті сервери, наскільки хороше мережеве з'єднання тощо), можливо, вам доведеться зробити більше роботи. Розділ реплікації документації MySQL висвітлює це більш докладно .

Я б запропонував вам забезпечити реплікацію через SSL (тобто встановити користувачу реплікації потрібне з'єднання SSL).

Реплікація кардинально змінилася в MySQL 5.1. У 5.0 було використано лише реплікацію на основі заяви. Тепер у вас є можливість зробити реплікацію на основі рядків або змішану реплікацію. Це значно вплине на реплікацію через WAN.

Якщо ви можете: Ми використовуємо внутрішній DNS з коротким кешуванням та підробленими внутрішніми доменами. Якщо нам потрібно змінити masterdb.internal, щоб бути якимось іншим сервером, через 5 секунд зміна пропигує.

У межах одного центру обробки даних ми використовуємо IP-передачу. Усі сервери БД мають віртуальні інтерфейси (eth0: 1, eth0: 2, eth0: 3), які не завантажуються під час завантаження. Якщо одному з рабів потрібно взяти на себе посаду, ви просто ifup eth0: 2 і це господар. У цьому сценарії eth0 - це "якщо", яке ми використовуємо для оболонки тощо. Програми підключаються до eth0: 1, яка не буде активована під час завантаження, якщо мій сценарій виявить, що IP-адреса прийнята. (Вікіпедія СТОНІТ) Інші ifs призначені для взяття IP-адрес майстрів, які, можливо, потребують невдалої спроби.

Я б не рекомендував перетинати океани при використанні реплікації MySQL. Я один раз намагався копіювати у господаря в Європі, поки раб був у техасі. Реплікація ламалася майже щодня, поки ми не відмовились від цього проекту. Звичайно, це може працювати, але воно, як правило, стає більш крихким, чим більше відстань між господарем і рабом.