Які недоліки використання кластера Galera замість реплікації Master / Slave?

Які недоліки використання кластера Galera замість звичайної реплікації Master / Slave? 0 рабського затримки Galera, синхронна реплікація та відсутність єдиної точки відмови здаються дуже привабливими, чому тоді кластер Galera не є звичайним?

— Сем
джерело

Відповіді:

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

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

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

"Галера" - це геніальна, але не технологія одного розміру. Є ще вагомі причини використовувати асинхронну реплікацію.

— Білл Карвін
джерело

Спасибі Білле, btw Я деякий час читав ваші презентації Percona.

— Сем

Іншим недоліком є те, що донорський вузол вимикає з себе і використовується для копіювання (за допомогою xtrabackup, rsync, mysqldump) на будь-який вузол, введений у кластер, залишаючи інші вузли в кластері, щоб зробити важкий підйом, поки новий вузол не синхронізується. Це не такий недолік для малих та середніх БД.

— RolandoMySQLDBA

@RolandoMySQLDBA Методи SST, такі як xtrabackup, точно уникають блокування донора. Хоча це правда, що в будь-якому випадку донор буде знижувати продуктивність, якщо база даних буде великою.

— jynus

@jynus, проблема не блокується на донорському вузлі, а в тому, що приймаючий вузол працює в автономному режимі та недоступний для будь-яких запитів, поки функціонує SST. Тому якщо ви використовуєте кластер для врівноваження навантаження запитів, запити, які пішли б у приймальний вузол, повинні бути надіслані іншим вузлам (ям), поки не буде виконано SST.

— Білл Карвін

У випадку, якщо хтось інший шукає, параметр, на який посилається Білл, є wsrep_causal_reads... встановити значення ON, SET GLOBAL wsrep_causal_reads = 'ON';щоб отримати вибір, щоб чекати, поки всі набори записів будуть виконані.

— Люк Двоюрідний

Деякі недоліки Galera включають:

Підтримка двигуна зберігання: обмежена InnoDB / XtraDB (плюс експериментальна підтримка для MyISAM)
Підтримка ОС: лише Linux / Unix-подібні Oses

Існують також деякі обмеження, які слід зазначити, але, можливо, їх можна вирішити:

За замовчуванням (Total Isolation Order) операції DDL блокують весь кластер до тих пір, поки вони не завершаться
Кожна таблиця повинна мати явний первинний ключ, або одинарний, або багатоколонний
Блокування: деякі види явного блокування не підтримуються.

Для отримання додаткової інформації дивіться деталі в Codership (і тут про блокування DDL), MariaDB та Percona .

EDIT: Зауважте також, що деякі стверджують, що щільно пов'язані кластери баз даних, такі як Galera, не повинні мати георозподілених вузлів через проблеми, що виникають із притаманної ненадійності мережевого рівня. Натомість в цих випадках повинні використовуватися асинхронні рішення. Дивіться: Як не робити MySQL Висока доступність: Розподіл географічних вузлів із неправильним використанням реплікації на основі Galera . Тим не менш, у блозі Galera зазначається, що (2015 р.):

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

— dbdemon
джерело