Узгодженість read-after-write у кластері Galera

Коміт означає сертифіковано, а не застосовано

Кластер Galera виконує транзакцію на одному вузлі. При коміті цей вузол розсилає write set кластеру, кожен вузол сертифікує його відносно write set, які вже в польоті, і коміт повертається клієнту. З цієї миті запис є довговічним у кластері і однаково впорядкованим усюди.

Чого ще не сталося, так це застосування. Кожен вузол бере сертифікований write set і застосовує його до власної копії даних у власних applier threads, трохи після того, як коміт повернувся. Працюють два годинники: сертифікація є загальнокластерною і частиною коміту, застосування є локальним і йде після. У здоровому кластері відстань між ними становить від десятків до кількох сотень мілісекунд. Вона зростає під час сплесків запису, великих транзакцій і змін схеми, і її видно як ненульовий wsrep_local_recv_queue на вузлі, що відстає.

Куди йде читання

Кластер з балансуванням читань надсилає читання туди, куди вирішить proxy. Один запит пише на вузлі A. Наступний запит того самого користувача, кілька сотень мілісекунд пізніше, читає на вузлі B. Якщо вузол B отримав, але ще не застосував write set, він відповідає рядком таким, яким той був до запису. З погляду вузла B відповідь правильна: це його закомічений стан. Нічого не логується, ніщо не тривожить, і монітор затримки мовчить, бо його побудовано ловити тривалу затримку, а не перші сто мілісекунд після однієї транзакції.

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

Як це виглядає в застосунку

Шаблон такий: запис, за яким одразу йде читання від того самого користувача, що потрапляє на інший вузол. У CMS це зниклий абзац: зберегти, оновити, старий текст, передрукувати, зберегти, і друге збереження перезаписує перше. У магазині це замовлення, якого не існує на сторінці підтвердження. У процесі автентифікації це токен, який щойно видали і не знайшли.

Два інші механізми дають схожу історію, і їх варто виключити першими. Back-forward cache браузера може відновити застарілу копію форми, і повторне збереження запише цю застарілу копію. Плагін може робити read-modify-write на тому самому рядку з двох запитів. Обидва реальні, і жоден не є кластером. Цикл, який пише мітку часу на одному вузлі і читає її з інших, розділяє їх за хвилину.

Налаштування: wsrep_sync_wait

wsrep_sync_wait є бітовою маскою. З установленим бітом 1 SELECT чекає, доки вузол застосує кожен write set, отриманий до цієї миті, перш ніж виконатися. Читанню тоді гарантовано побачити все, що було закомічено будь-де в кластері до його початку. Його можна встановити для однієї сесії, що є правильним обсягом для редактора або шляху оформлення замовлення, або глобально, коли все навантаження чутливе до read-after-write.

-- for one session: the request path that writes and then reads
SET SESSION wsrep_sync_wait = 1;

-- for the whole node: my.cnf, under [mysqld]
wsrep_sync_wait = 1

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

Чого це коштує і де за це платити

Читання під wsrep_sync_wait чекає, доки локальний applier наздожене, тому воно платить затримку застосування один раз на кожне читання, що йде за записом. У здоровому кластері це від десятків до кількох сотень мілісекунд. Сесії авторизованих користувачів, шляхи адміністраторів і редакторів та оформлення замовлення є тими місцями, де ця ціна щось купує. Анонімні сторінки, які віддаються з edge-кешу, при влучанні не торкаються бази даних і не зачіпаються. Налаштування набирає чинності з наступного оператора і так само скасовується, тож його можна виміряти на місці зі справжнім навантаженням, а не оцінювати.

Як перевірити власний кластер

Три показники все вирішують. Чи читання взагалі чекають; наскільки відстає вузол під час сплеску запису; і як часто міжвузлове read-after-write насправді бачить минуле, з циклу, який пише на одному вузлі і читає з інших.

SHOW GLOBAL VARIABLES LIKE 'wsrep_sync_wait';        -- 0 means reads do not wait
SHOW GLOBAL STATUS LIKE 'wsrep_local_recv_queue';    -- received, not yet applied

Ми експлуатуємо кластери Percona XtraDB з балансуванням читань за ProxySQL і HAProxy і можемо відповісти на ці три запитання для будь-якого кластера, яким керуємо, включно з тим, чого коштує це налаштування на тому конкретному навантаженні.