Як читати стан кластера Galera за п’ятьма змінними стану

Кластер Galera (Percona XtraDB Cluster або MariaDB Galera) може виглядати з боку застосунку цілком нормально, поки тихо працює на двох ногах, пригальмовує сам себе або тримає вузол, якому для повернення знадобиться повна копія. Кожен із цих станів видно в кількох змінних стану. Ось як ми їх читаємо і що кожна з них вам каже.

Проблема: «відповідає на запити» не є перевіркою стану

Більшість моніторингу для кластерної бази даних перевіряє те саме, що й для одиночного сервера: чи відкритий порт 3306, чи повертається SELECT 1. Вузол Galera, який випав з primary component, і далі приймає підключення. Вузол, який синхронізований, але застосовує записи надто повільно, і далі відповідає на читання. Кластер із трьох, що тихо став кластером із двох, і далі обслуговує сайт, аж до моменту, коли зникне наступний вузол і кворуму не стане.

Кластер знає все це про себе. Треба лише запитати.

Один запит, який треба виконати на кожному вузлі

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_status',
  'wsrep_cluster_size',
  'wsrep_local_state_comment',
  'wsrep_ready',
  'wsrep_cluster_state_uuid',
  'wsrep_flow_control_paused',
  'wsrep_local_recv_queue_avg',
  'wsrep_local_send_queue_avg',
  'wsrep_local_cert_failures',
  'wsrep_local_bf_aborts'
);

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

Членство: чи цей вузол справді частина кластера?

wsrep_cluster_status має бути Primary. Усе інше (Non-Primary, Disconnected) означає, що цей вузол втратив зв’язок з більшістю і відмовиться віддавати консистентні дані. Якщо ваша перевірка стану не дивиться на це значення, відокремлений вузол може й далі отримувати трафік.

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

wsrep_local_state_comment має показувати Synced. Donor/Desynced означає, що вузол годує нового учасника і може бути сповільнений; Joining і Joined означають, що він ще доганяє. Вузол у будь-якому стані, крім Synced, ваш proxy має виводити з пулу читання, доки той не повернеться.

wsrep_cluster_state_uuid має бути однаковим на кожному вузлі. Два різні значення означають, що у вас два кластери, кожен з яких вважає себе кластером. Таке трапляється лише після того, як хтось зробив bootstrap не того вузла, тож це варто перевіряти після будь-якого ручного відновлення.

wsrep_ready просто підтверджує, що вузол прийматиме запити; якщо він показує OFF, інші значення скажуть чому.

Продуктивність: чи кластер сам себе стримує?

Реплікація Galera базується на сертифікації: кожен вузол має погодитися, що write set не конфліктує, перш ніж він буде зафіксований. Це робить кластер таким швидким, як його найповільніший applier, і Galera забезпечує це через flow control.

wsrep_flow_control_paused є часткою часу з моменту останнього FLUSH STATUS, протягом якої реплікацію було призупинено, бо якийсь вузол не встигав. Читайте його як відсоток. Близько нуля означає здоровий стан. Усе, що стабільно вище кількох відсотків, означає, що записи чекають на повільний вузол, і затримка запису вашого застосунку за це платить. Зробіть flush, зачекайте відомий інтервал, прочитайте знову, щоб число описувало теперішнє, а не минулий місяць.

wsrep_local_recv_queue_avg каже, який саме вузол повільний. Вузол, у якого середнє значення черги прийому тримається помітно вище нуля, і є тим, що запускає flow control. Зазвичай причина локальна: повільніше сховище, галасливий сусід, довгий звіт або замало applier threads (wsrep_applier_threads, або wsrep_slave_threads у старіших випусках).

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

Конфлікти: чи пишете ви більш ніж на один вузол?

wsrep_local_cert_failures і wsrep_local_bf_aborts рахують транзакції, відкочені через те, що інший вузол першим зафіксував конфліктну зміну. Застосунок бачить їх як помилки deadlock. Стабільна цівка таких подій на кластері, де кожен вузол приймає записи, є ознакою конкуренції кількох writer, і плагіни WordPress та e-commerce, які оновлюють одні й ті самі рядки option чи лічильників на кожен запит, виробляють її у великих кількостях.

Виправлення архітектурне, а не ручка налаштування: надсилайте всі записи на один вузол і розподіляйте читання. З ProxySQL це один рядок:

INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
   offline_hostgroup, active, max_writers, writer_is_also_reader,
   max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

max_writers = 1 обирає одного writer, інші стають reader і резервними writer, а max_transactions_behind дозволяє ProxySQL автоматично виводити вузол, що відстає, з пулу читання. Щойно записи йдуть на один вузол, ці два лічильники мають майже завмерти.

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

Повернення: вузол повернеться швидко чи повільно?

Вузол, який виходить і повертається, отримує або пропущені write sets з кешу донора (IST, інкрементально і швидко), або повну копію набору даних (SST, повільно і важко для донора). Що саме ви отримаєте, залежить від того, чи кеш write sets донора, gcache.size у wsrep_provider_options, досі містить усе, що пропустив новий учасник.

Його можна розрахувати з власних лічильників кластера. Прочитайте wsrep_replicated_bytes і wsrep_received_bytes з інтервалом у годину; сума різниць приблизно дорівнює обсягу write sets за годину. Помножте на найдовше вікно обслуговування, яке очікуєте, додайте запас, і це потрібний вам gcache. Тоді вузол можна оновити, перезавантажити або тримати годинами на роботах з обладнанням, і він усе одно повернеться інкрементально.

Кворум: арифметика за словом «три»

Кворум є строгою більшістю. Три члени витримують втрату одного. Чотири члени також витримують лише одного, бо два з чотирьох не є більшістю, тож четвертий вузол купує потужність, але не стійкість. Два члени не витримують нічого: якщо вони втрачають одне одного з поля зору, обидва зупиняються. Якщо у вас справді лише два вузли з даними, додайте арбітр Galera (garbd) на третьому, незалежному хості, щоб більшість існувала.

Та сама арифметика стосується того, де живуть члени. Три вузли на одному хості або три вузли, дані яких лежать на одному масиві сховища, є одним доменом відмови під трьома іменами. У Kubernetes поєднуйте жорстку pod anti-affinity з PodDisruptionBudget minAvailable: 2, щоб rolling update вузлів ніколи не міг забрати двох членів одночасно.

Що перевірити на власному кластері цього тижня

• Кожен вузол звітує Primary, Synced, однаковий state UUID і той розмір кластера, який ви спроєктували.
• Ваша перевірка стану і ваш proxy обидва використовують ці значення, а не лише TCP connect.
• wsrep_flow_control_paused, виміряний за свіжий інтервал, близький до нуля.
• Відмови сертифікації не зростають; якщо зростають, записи потрапляють більш ніж на один вузол.
• Ваш gcache покриває найдовше заплановане вікно обслуговування.
• Жодні два члени не ділять хост, масив або (у Kubernetes) disruption без бюджету.

Кластер Galera, який читають так, рідко когось дивує. Якщо ваш дивує, ми радо подивимося.

cta: Поговоріть з інженером

Related

• /what-we-do/data-web/clustered-databases/
• /what-we-do/data-web/database-replication/
• /what-we-do/data-web/high-availability-platforms/