Запис не можна балансувати.
Однакові вузли бази даних виглядають як помножена потужність запису. Розподіліть ваші записи між ними, і кластер почне виробляти deadlock. Дизайн, який працює.
У цій статті 2 розділів
- Інтуїтивне налаштування кластера: однакові вузли, один балансувальник, усе по колу. Це виглядає як помножена потужність.
- Під цілком нормальним навантаженням воно видає помилки deadlock редакторам посеред публікації, без жодної помилки блокування в коді. Два редактори, два вузли, один гарячий рядок, і перевірка конфліктів кластера відкидає одного з них.
- Контрінтуїтивне виправлення: кожен запис іде на один обраний вузол, а розподіляються лише читання.
- Поворот, який відповідає на «але хіба розподіляти не швидше?»: обсяг записів рідко є обмеженням. Масштабується потужність читання, а помилки зникають.
Ви купили кластер бази даних. Ніхто не купує кілька екземплярів чогось, щоб використовувати один, тож конфігурація балансувальника практично пишеться сама: усе по колу через кожен вузол. Переконання під цим просте: один запит не стане швидшим, але багато стануть, поділені між машинами. Звучить очевидно правильно. Це також найпоширеніший спосіб, яким, як ми бачимо, зловживають цим класом кластерів.
Помилка, якої немає в коді
Під звичайним навантаженням редактори час від часу натискають «зберегти» й отримують назад сиру помилку бази даних через CMS: deadlock found. Вона періодична, її важко відтворити, і жодне читання коду застосунку її не знайде, бо помилка не в коді.
Навантаження, що стає зброєю, є звичайним. CMS переписує жменю глобально іменованих рядків конфігурації майже при кожній дії. SEO-плагін перебудовує свій sitemap при кожному збереженні. Часові мітки входу й лічильники переглядів торкаються тих самих гарячих рядків. Round-robin розкидає ці конкуруючі записи по кожному вузлу. Кожен вузол приймає свій запис локально, а потім крок сертифікації кластера ловить колізію в момент коміту й кидає її назад клієнту, який не зробив нічого поганого. Два редактори, два вузли, той самий рядок: помилка 1213.
Deadlock під нормальним навантаженням, на кластері, без жодного шаблону блокування в застосунку, є симптомом маршрутизації. Навантаження не є неправильним. Неправильною є топологія.
Single-writer заради безпеки, читання розподіляйте
Чи марнує спрямування всіх записів на один вузол решту? Ні. Читання рівномірно балансуються по кластеру, а кожен запис іде на єдиний обраний writer. Інстинкт round-robin правий щодо читань і неправий щодо записів; маршрутизація single-writer зберігає праву половину й видаляє помилки, які породжує інша половина. Якщо ваш перший інстинкт на завантаженому кластері полягає в тому, щоб масштабуватися вгору, суміжний урок каже, що правильний крок часто є протилежним (зменшуйте, а не збільшуйте).
1213
1
“Кластер є multi-primary-capable і single-writer-safe. Це різні речення.”
Якщо у вас працює кластер зі збалансованими читаннями, підіть з'ясуйте, куди насправді потрапляють ваші записи. Якщо відповідь «туди, куди балансувальник випадково їх надішле», ви за один завантажений вечір від того, щоб виробляти deadlock з власного успіху. Перевірка коштує одного читання конфігурації. Виправлення є правилом маршрутизації, а не переписуванням.
Прямі відповіді
Чому я отримую помилки deadlock (1213) на своєму кластері Galera або PXC під нормальним навантаженням?+
Якщо у вашому коді немає помилки блокування, перевірте маршрутизацію записів. Записи, розкидані по вузлах, стикаються на гарячих рядках у момент сертифікації, і кластер повідомляє про колізію як про deadlock невинному клієнту. Спрямуйте кожен запис на один вузол, і весь цей клас помилок зникне.
Хіба надсилання всіх записів на один вузол не марнує мій кластер?+
Записи майже ніколи не є вузьким місцем; обсяг дають читання. З маршрутизацією single-writer читання все одно балансуються по кожному вузлу, а пропускна здатність запису не змінюється, бо фактично один вузол завжди виконував усю роботу із запису.
Чи може кластер Galera робити записи multi-master?+
Він здатен приймати записи на кожному вузлі, і це безпечно, коли йому не доводиться сертифікувати конкуруючі записи в гарячі рядки з кількох вузлів одночасно. Multi-primary-capable, single-writer-safe. Використовуйте цю здатність для failover, а не для розподілу навантаження.
Як тоді масштабувати записи бази даних?+
Спершу доведіть, що це потрібно: виміряйте обсяг записів проти запасу єдиного writer, що зазвичай є похибкою округлення поряд із читаннями. Справжнє масштабування записів є територією шардингу або перепроєктування навантаження, а не налаштуванням балансувальника.
Що маршрутизує читання й записи по-різному?+
Проксі-шар, який говорить протоколом бази даних, може їх розділити: читання розподіляються, записи закріплюються за обраним writer, а failover автоматично переобирає writer. Ми використовуємо цей шаблон у робочому середовищі: ProxySQL перед Percona XtraDB Cluster.
Бачите deadlock, яких не можете знайти у своєму коді?
Надішліть нам лише помилку і те, як збалансований ваш кластер. Якщо справа в топології, ми вам покажемо й виправимо в маршрутизації, а не у вашому застосунку.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером