Як швидко відбувається реплікація MySQL?

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

Сам db не такий великий (<1gb), але мені цікаво; враховуючи 200-300 оновлень запису / хв вершин: наскільки швидка реплікація? (якщо припустити, по-перше, загальний підключення dsl 5 Мб, швидше, якщо потрібно - намагайтеся максимально знизити витрати, але грошей є більше)

Чи цілі таблиці копіюються партіями? Чи робиться реплікація на вимогу, оскільки кожен запис у таблиці оновлюється (з документів, я думаю, я бачу, що це налаштовується)?

Примітки:

• Я думаю, що налаштування 1 майстра, 2 раби (2 відділення на даний момент), як у документах тут, за винятком того, що це додаток, а не веб-клієнт
• Будь-яке оновлення, зроблене на ведучому, повинно повторюватись на інші раби через <10 хв.
• Все це передбачає, що я можу задовольнити наш ORM (DevExpress XPO) з концепцією читання від раба і письма майстру.

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

Мультимайстерна реплікація робить те саме, але в обох напрямках.

Деякі основні розрахунки допоможуть вам краще визначити ваші потреби в пропускній здатності.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Сподіваюсь, це допомагає.

Реплікація на стороні рабів обробляється двома незалежними нитками.

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

Затримка реплікації обмежена IO, по-перше, IO у веденій базі даних, щоб застосувати транзакції з журналу ретрансляції (який може включати складні запити SQL), а по-друге, IO на головний майстер, щоб прочитати його бінлог і передати його кожному веденому.

Реплікація MySQL збільшує можливість запиту читання, але не збільшує продуктивність запиту запиту, яка зі швидкістю IO, яка може бути передана у бінлог як на головний, так і на ведений

Реплікація в MySQL досить швидка, щоб отримати дані в підлеглий (швидше, ніж ви зможете запустити UPDATEмайстер і перейти в інше вікно, щоб запустити SELECTна підлеглому, якщо(і лише якщо) мережеві з'єднання налаштовані, і все працює добре. Будь-яке з'єднання класу DSL має бути нормальним для загальних випадків ваших звичайних невеликих запитів, але для великих запитів на вставлення / оновлення може знадобитися небагато часу, щоб скопіювати та повторно синхронізуватись у випадку запуску реплікації (і MySQL злісно схильний до їх, на жаль, знадобиться певний час (знову копіювання всієї бази даних від майстра). Існують хитрощі щодо обмеження впливу ресинхронізації на вашого майстра, як, наприклад, розміщення MySQL на LVM, щоб ви могли зробити дуже швидке блокування / знімок та rsync вміст знімка до ведомого, але в кінцевому підсумку ресинхроніка збирається засмоктувати.