Чи впливає реплікація MySQL на високоздатний взаємозв'язок?

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

Пропускна здатність між центром обробки даних є досить високою (у мережевих орієнтирах, які ми зробили, ми можемо досягти 15 Мб / секунду), але затримка існує, вона становить близько 28 мс. Він не високий будь-яким способом, але набагато перевищує затримку в другій секунді в тому ж центрі обробки даних.

Інколи ми відчуваємо серйозні відставання (2000 секунд і більше) з вивільненим веденим, тоді як місцевий раб залишається в курсі. Переглядаючи відсталий підлеглий ведений, потік SQL зазвичай витрачає час в очікуванні потоку IO для оновлення журналу ретрансляції. Майстер показує "очікування на сітку" або щось подібне одночасно.

Це означає, що це мережа, але ми все ще маємо вільну пропускну здатність на той час, коли це відбувається.

Моє запитання : чи може затримка між центрами обробки даних впливати на ефективність реплікації? Чи невільницький потік io просто передає події, поки господар не перестає їх надсилати, або він об'єднує майстра якось між подіями?

Пряма відповідь на ваше запитання - Так, але це залежить від запущеної версії MySQL. Перед MySQL 5.5 реплікація діяла б так:

• Майстер виконує SQL
• Майстер записує подію SQL у своїх бінарних журналах
• Slave читає подію SQL з головних бінарних журналів
• Slave зберігає події SQL у своїх журналах ретрансляцій через введення-виведення
• Slave читає наступну подію SQL з журналу ретрансляцій через SQL Thread
• Slave Виконує SQL
• Slave визнає майстра повного виконання події SQL

Як і в MySQL 5.5, використовуючи Semisynchronous Replication , тепер реплікація діятиме наступним чином:

• Майстер виконує SQL
• Майстер записує подію SQL у своїх бінарних журналах
• Slave читає подію SQL з головних бінарних журналів
• Slave визнає майстра отримання SQL події
• Slave зберігає події SQL у своїх журналах ретрансляцій через введення-виведення
• Slave читає наступну подію SQL з журналу ретрансляцій через SQL Thread
• Slave Виконує SQL
• Slave визнає майстра повного виконання події SQL

Ця нова парадигма дозволить Рабу бути ближче синхронізуватися з його Наставником.

Незважаючи на те, затримка в мережі може перешкоджати реплікації MySQL Semisync до того моменту, коли вона повертається до асинхронної реплікації старого стилю. Чому? Якщо тайм-аут настає, коли будь-який підлеглий не підтвердив транзакцію, ведучий повертається до асинхронної реплікації. Коли щонайменше один напівсинхронний раб наздоганяє, ведучий повертається до напівсинхронної реплікації.

ОНОВЛЕННЯ 2011-08-08 14:22 EDT

Конфігурація напівсинхронної реплікації MySQL 5.5 проста

Крок 1) Додайте ці 4 (4) рядки до /etc/my.cnf

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
#rpl_semi_sync_master_enabled
#rpl_semi_sync_master_timeout=5000
#rpl_semi_sync_slave_enabled

Крок 2) Перезавантажте MySQL

service mysql restart

Крок 3) Запустіть ці команди в клієнті MySQL

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave  SONAME 'semisync_slave.so';

Крок 4) Відмініть три варіанти rpm_semi_sync після параметра plugin-dir

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_slave_enabled

Крок 5) Перезавантажте MySQL

service mysql restart

Все зроблено !!! Тепер просто налаштуйте MySQL Replication як завжди.

Мені дуже подобається, як Роландо описав послідовність операцій, які виконує реплікація. Однак, я думаю, було б зрозуміліше, якщо ми додамо ще один компонент - клієнт.

З клієнтом послідовність операцій для асинхронної реплікації може бути такою:

1. Клієнт відправляє майстру SQL-запит (наприклад, вставити) за допомогою транзакцій

2. Майстер виконує транзакцію. У разі успіху запис зберігається на диску, але транзакція ще не здійснена.

3. Мастер записує подію вставки у головний бінарний журнал Якщо господар не зміг зберегти її у двійковому журналі, транзакція відкотилася назад.

4. Клієнт отримує відповідь від ведучого (успіх або відкат).

5. У разі успіху транзакції, дамп-потік на ведучому зчитує подію з бінарного журналу та відправляє її в підлеглий потік вводу-виводу.

6. Потокова введення-виведення потоку приймає подію і записує її в кінець файлу журналу ретрансляції.

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

У цьому сценарії майстер не піклується про підлеглого, і клієнт лише знає, що на підлеглому щось не так, виконуючи вручну команду "SHOW SLAVE STATUS".

У випадку напівсинхронної реплікації послідовність операцій може бути такою:

1. Клієнт відправляє майстру SQL-запит (наприклад, вставити) за допомогою транзакцій.

2. Майстер виконує транзакцію. У разі успіху запис зберігається на диску, але транзакція не здійснюється.

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

4. Завдяки успіху транзакції на ведучому, дамп-потік на ведучому зчитує подію з двійкового журналу та надсилає її до підлеглого потоку вводу-виводу.

5. Потокова введення-виведення потоку приймає подію і записує її в кінець файлу журналу ретрансляції.

6. Slave визнає майстра запису події у файлі журналу ретрансляції.

7. Master здійснює транзакцію вставки.

8. Клієнт отримує відповідь від майстра (успіх).

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

Напівсинхронна реплікація вирішила один важливий випадок, коли раб або мережа померли і господар продовжував продовжувати. Потім майстер гине, і ви хочете перезапустити старого раба як нового господаря лише тому, що ви зафіксували цей вузол.

Отже, ви запустили цей вузол як новий головний, ви зафіксували старого майстра і тепер ви хочете використовувати його як раб. Цей вузол все ще має дані, але якщо новий підлеглий починається з позиції, з якої розпочався новий ведучий, то будуть повторювані записи.

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

Я думаю, що це дуже реально. Один з найпоширеніших випадків відмови підлеглого запиту - "копія запису". Де дублікат записів прийшов до раба, якщо у господаря його не було? Це прийшло з неправильного положення, даного рабу, щоб почати копіювати. Початкова позиція реплікації включала запис, який вже був реплікуваний. У разі напівсинхронної реплікації такої ситуації не відбудеться.

Яків Ніком

Кваліфікатор : Я не є користувачем MySQL, тому в основному це лише моє дослідження в Інтернеті.

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

За тут :

Одне, що вам потрібно зробити, це скоротити час трансакції. Це дозволяє вашому потоку реплікації мати можливість наздогнати те, що відбувається в базі даних. Ви хочете, щоб ваші транзакції були максимально короткими.

Один із способів зробити це - подрібнення запитів; обмежте рядки, змінені UPDATE або DELETE за допомогою пунктів WHERE. Якщо ви вставите це всередині циклу, ви можете повторити список, щоразу починаючи та здійснюючи транзакцію. (ОНОВЛЮЙТЕ / ВИДАЛУЙТЕ першу третину, другу третину, потім фінальну третину в кожній власній транзакції.) Я особисто настійно радив би цього не робити, оскільки ви відкриваєте себе перед можливістю зміни даних у таблиці між транзакціями. Але є можливість покращити цю ефективність, якщо ви впевнені, що ніхто більше не возиться зі столом (і ніколи не буде) .

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

За тут :

Останньою можливістю буде налаштування розміру ваших буферів TCP. Мета - зменшити кількість комунікацій, які ви здійснюєте між ведучим і рабом. Це може допомогти зменшити затримку.

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

Закладки JHammerb's Delicious мають кілька посилань для реплікації mysql, які ви також можете перевірити.

Я сподіваюся, що це допомагає.