Рішення для масштабування MySQL (реплікація, кластеризація)

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

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

Я багато читав доступних варіантів. Я також взяв у руки високопродуктивний MySQL 2nd edition, який я настійно рекомендую.

Це те, що мені вдалося скласти:

Скупчення

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

Кластер NDB MySQL

Кластер MySQL NDB - це розподілений в пам’яті механізм зберігання даних із спільним використанням даних із синхронною реплікацією та автоматичним розподілом даних (вибачте, я позичаю буквально з книги «Висока продуктивність», але там це дуже гарно викладено). Це може бути високопродуктивним рішенням для деяких додатків, але веб-додаток, як правило, не працює з ним добре.

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

Крім того, потреба в пам’яті не діє для багатьох великих баз даних.

Постійна секвойя

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

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

Федерація

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

Реплікація та балансування навантаження

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

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

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

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

Заточування та розділення

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

Доступні фреймворки абстракції, які допоможуть вирішити питання з шардінгом даних, такі як Hibernate Shards , розширення Hibernate ORM (що, на жаль, є на Java. Я використовую PHP). HiveDB - ще одне таке рішення, яке також підтримує перебалансування осколків .

Інші

Сфінкс

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

Взагалі сфінкс слід використовувати з іншими рішеннями для масштабування, щоб отримати більше доступного обладнання та інфраструктури. Недоліком є ​​те, що вам знову потрібен код програми, щоб знати про сфінкса, щоб використовувати його розумно.

Резюме

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

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

Застереження: я не використовував кластер MySQL, тому переходжу лише до того, що чув.

Кластер MySQL - це рішення HA (висока доступність). Це швидко, тому що все це в пам’яті, але справжнім продажем є наявність. Немає жодної точки відмови. З іншого боку, при реплікації, якщо майстер не працює, вам доведеться фактично перейти до репліки, і може бути невеликий час простою. (хоча рішення DRBD є ще однією альтернативою, яка має високу доступність)

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

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

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

Є кілька хороших дискусій про те, як люди, які підтримують drupal.org, структурували свої сервери баз даних:

• Блог Дріса Буйєрта
• Блог WorkHabits

Обидва вони з 2007 року, тому підтримка кластеризації може бути зараз потужнішою, але на той час вони вибрали реплікацію.

Найцікавіше в реплікації полягає в тому, що це легко. Просто встановіть 2 поля mysql, змініть ідентифікатор сервера на другому полі, а потім наведіть друге поле на перше, використовуючи команду зміни майстра.

Ось відповідний зразок підпорядкованої конфігурації my.cnf

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

Тож переконайтесь, що кожен підлеглий отримує ідентифікатор сервера, збільшений на 1 (таким чином, наступний підлеглий - це сервер 3)

встановіть ім'я користувача та пароль, до яких ведений може підключитися, а потім запустіть master master до MASTER_HOST = 'xxxx'; змінити master на MASTER_PASSWORD = "xxxxx";

і так далі.

нарешті, запустіть "start slave;"

Вгору приходить твій раб і починає тиражувати. солодке га!

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

Ви можете перевірити статус веденого, запустивши:

показати статус підлеглого \ G

Веселіться з цим .. оооочень легко ...

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

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

За допомогою різних режимів управління транзакціями, що надаються DRBD, ви можете зменшити продуктивність, що вражається реплікацією даних на рівні пристрою через мережу. Для надійної системи, яка не повинна втратити жодної транзакції у випадку відмови, використовуйте режим C, інакше перейдіть до B.

Я спробував перерахувати деякі знання, які я зробив під час налаштування кластера DRBD, за адресою http://www.techiegyan.com/?p=132

Це дуже добре працює на виділеному з'єднанні для реплікації, тобто резервує окремі високошвидкісні інтерфейси на обох машинах лише для реплікації drbd. Heartbeat може чудово управляти кластером за допомогою всіх служб по одному, тобто IP-адреси, розділи, drbd та mysql.

Я ще не відкрив конфігурацію Master-Master на DRBD. Буде оновлюватись як і коли я досягну в цьому успіху.

Дякую.

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

У нашому налаштуванні ми запускаємо кластер MySQL та Mnesia. Наші дані є якимось сезонним. Отже, що відбувається через деякий час, ми звільняємо мнезію даних, які більше не використовуються, і передаємо їх у кластер MYSQL. Це підтримує ефективність нашої мнезії. Також у нас є програми, реалізовані на основних мовах потоку (Python, Clojure тощо), які використовують дані безпосередньо з MySQL.

У двох словах, ми запускаємо mnesia поверх кластера MySQL. Кластер MySQL може обробляти великі набори даних, база даних може зрости до 50 Гб плюс. У нас є Мнезія, яка живить програми Erlang / OTP . Java та PHP отримують доступ до даних з mnesia через спеціальні API REST (нещодавно Thrift ), що використовують JSON та XML як формати обміну.

Рівень доступу до даних має абстрагований доступ до даних у Мнезії та старих переданих даних у кластері MySQL, якщо це необхідно. Mnesia тут, по суті, працює для роботи додатків Erlang / OTP. Після того, як він отримує дані, ми передаємо їх у кластер MYSQL. Рівень доступу до даних може отримувати доступ як до даних в mnesia, так і до MySQL в абстрактному API від імені всіх програм.

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

Раніше ми боялися, що mnesia може не обробляти якомога більше записів через обмеження розміру таблиці. Але ми визнали це твердження неправильним. За належного налаштування (фрагментації) наші бази даних про Мнезію містять в середньому близько 250 мільйонів записів на рік.

Ми отримали користь від складної структури даних Ерланга та від того, що Мнезія може проковтнути їх без змін. Програми Erlang / OTP є найбільш ефективними з усіх інших програм на застарілих мовах, і з нашою системою ми плануємо перенести все це на технологію Erlang / OTP. З Erlang ми, мабуть, отримуємо доступ до даних кластера MySQL і чудово виконуємо запити на його серверах. Насправді ми зробили висновок, що його Erlang / OTP може повною мірою використовувати ресурси сервера MySQL через свою суттєву паралельність (Erlang).

Mnesia працював для нас дуже добре. Mnese повністю змінив наш погляд на бази даних завдяки своїм захоплюючим показникам. Наші серверні процесорні ядра Solaris зайняті в середньому близько 48% використання в пікові години.

Я раджу вам перевірити mnesia, і хто знає, це може відповісти на деякі ваші потреби у розповсюдженні чи тиражуванні.

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

Обмеження «в пам’яті» заважає нам використовувати кластер MySQL для наших майже 50 Гб даних, тому ми використовуємо DRBD плюс Linux Heartbeat .

Це ніби схоже на рейдовий масив між двома (або більше) вікнами, який підтримує синхронізацію баз даних / журналів / конфігурацій (але одночасно може «жити» лише один сервер). Відмовний перехід відбувається автоматично, використовує ту саму IP-адресу та швидко, як перезапуск mysql, тому це було хорошим рішенням для нас.

Кластер MySQL - це дивна тварина, і кожного разу, коли ми оцінювали, він або працював дуже погано, або був ненадійним.

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

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

Але я дійсно вважаю, що він більше підходить для цілком спеціальних випадків, для яких він був розроблений. У більшості випадків він не може замінити інший механізм бази даних (наприклад, InnoDB) ні за продуктивністю, ні за функціями.