Операційні вимоги для «Як працювати з резервним вузлом під час оновлення» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Резервний вузол (hot standby) — це повноцінна копія вашого валідатора, яка синхронізується з мережею в реальному часі, але не голосує. Під час оновлення основного вузла саме резервний забезпечує безперервність роботи: якщо оновлення піде не за планом, ви переключаєте голосування на резерв за хвилини, а не відновлюєте вузол з нуля годинами. Нижче — повний операційний цикл від архітектури до зворотного переключення.

Архітектура з резервним вузлом

Схема передбачає два фізичні сервери в різних точках присутності, кожен із власним identity-ключем. Ключі налаштовуються так, що обидва identity можуть голосувати від імені одного валідаторного акаунта — для цього на аккаунті валідатора реєструється обидва public key через інструкцію authorize.

Базова топологія:

  • Вузол A (основний) — активний, голосує, обслуговує RPC (якщо застосовується), приймає інгрес-трафік.
  • Вузол B (резервний) — синхронізований, не голосує, слухає мережу, готовий прийняти роль основного.
  • Загальне — обидва підключені до однакових наборів ingress-пірів, мають однакову конфігурацію ledger та accounts.

Критична вимога: identity-ключі мають бути різними, але обидва авторизовані на валідаторному аккаунті. Не використовуйте один і той самий ключ на двох вузлах одночасно — це призведе до дублювання голосів і штрафів.

Передумови для реалізації:

  • Два сервери з однаковими або еквівалентними характеристиками (CPU, RAM, NVMe).
  • Два окремі identity-ключові пари.
  • Авторизація обох ключів на валідаторному аккаунті (зверніть увагу на поточні правила авторизації в документації клієнта — вони можуть змінюватися).
  • Моніторинг синхронізації обох вузлів (slot, epoch, skip rate).

Синхронізація резервного вузла

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

Ключові параметри запуску резервного вузла (Agave, перевірено на Ubuntu 24.04 LTS):

  • --no-voting — вузол не відправляє голоси.
  • --identity — вказується окремий ключ резервного вузла.
  • --known-validator — список довірених валідаторів для ingress-фільтрації (ідентичний до основного).
  • --expected-genesis-hash — обов'язково, щоб уникнути підключення до неправильного кластера.

Перевірка стану синхронізації:

  • solana slot — має збігатися з поточним слотом мережі з відхиленням не більше ніж кілька слотів.
  • solana catchup — має показувати yes або відсутність відставання.
  • Лог вузла — відсутність повідомлень "skipping slot" у великій кількості.

Типова проблема: резервний вузол відстає через недостатню пропускну здатність диска або мережі. Якщо відставання перевищує 100–200 слотів стабільно, резервний непридатний для переключення — спочатку усуньте причину відставання.

Оновлення основного вузла з активним резервом

Коли резервний підтверджено синхронізованим, ви можете безпечно зупинити основний вузол для оновлення. Процедура:

  1. Перевірте стан резервного — виконайте solana slot і solana catchup на вузлі B. Переконайтеся, що відставання мінімальне.
  2. Зупиніть голосування на вузлі A — виконайте solana validator withdraw-all-stake або просто зупиніть сервіс (systemctl stop solana). Вузол перестане голосувати, і мережа не буде очікувати його голосів.
  3. Оновіть бінарний файл на вузлі A — завантажте нову версію клієнта, замініть бінарник, перевірте версію командою agave-validator --version.
  4. Запустіть вузол A без голосування — додайте --no-voting до конфігурації або запуску. Дайте йому синхронізуватися до поточного слота.
  5. Перевірте стабільність — переконайтеся, що вузол A не крашиться, логи чисті, слот наздоганяє мережу.
  6. Увімкніть голосування на вузлі A — приберіть --no-voting і перезапустіть сервіс.

Ризик: якщо на кроці 4 вузол A не може синхронізуватися (наприклад, несумісність леджера з новою версією), ви маєте працюючий резервний вузол B, на який можна переключити голосування негайно.

Попередження: ніколи не залишайте обидва вузли з увімкненим голосуванням одночасно. Це призведе до дублювання голосів і потенційного slashing.

Переключення ролей при проблемах

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

  1. Підтвердьте, що вузол A не голосує — перевірте процеси, логи, статус сервісу. Якщо є сумніви, вбийте процес примусово.
  2. Увімкніть голосування на вузлі B — приберіть --no-voting з конфігурації та перезапустіть сервіс: systemctl restart solana.
  3. Перевірте, що вузол B голосує — виконайте solana validators або перевірте лог на наявність записів "vote sent".
  4. Зафіксуйте проблему на вузлі A — збережіть логи, зробіть копію леджера (якщо потрібно для діагностики), але не видаляйте нічого, поки проблема не зрозуміла.

Час переключення за нормальної роботи інфраструктури — 2–5 хвилин. Основний споживач часу — перевірка того, що вузол A дійсно мовчить.

Типова помилка: переключення на резервний, який фактично відставав, але ви цього не перевірили. Результат — резервний починає голосувати з відставанням, пропускає слоти, репутація валідатора страждає. Завжди перевіряйте solana catchup перед увімкненням голосування.

Зворотне переключення після успішного оновлення

Коли вузол A успішно оновлено, стабільно працює і синхронізований, поверніть його в активну роль:

  1. Перевірте синхронізацію вузла A — solana slot і solana catchup мають показувати повну готовність.
  2. Зупиніть голосування на вузлі B — додайте --no-voting і перезапустіть, або зупиніть сервіс.
  3. Увімкніть голосування на вузлі A — приберіть --no-voting, перезапустіть.
  4. Перевірте голосування вузла A — логи, solana validators.
  5. Переконайтеся, що вузол B не голосує — фінальна перевірка логів вузла B.

Після зворотного переключення резервний вузол продовжує працювати в режимі --no-voting, підтримуючи синхронізацію. Це його стандартний стан між оновленнями.

Вартість та складність резервного вузла

Резервний вузол — це повноцінний сервер з тими самими апаратними вимогами, що й основний. Він споживає ресурси постійно: процесор на відтворення леджера, мережевий трафік, дисковий I/O, оперативну пам'ять. Тобто ви фактично подвоюєте інфраструктурні витрати на валідатор.

Складність управління включає:

  • Підтримку двох серверів — оновлення ОС, моніторинг, заміна дисків, мережове обслуговування — все подвоюється.
  • Синхронізацію конфігурації — будь-яка зміна списку known-validator, параметрів мережі, правил фаєрвола має бути застосована на обох вузлах.
  • Авторизацію ключів — додаткова операційна складність при ротації ключів або зміні авторизованих identity.
  • Моніторинг двох точок — алерти мають покривати обидва вузли, а панель моніторингу має чітко показувати, який вузол активний, а який резервний.

Резервний вузол виправданий для операторів, які:

  • підтримують RPC-інфраструктуру з жорсткими SLA;
  • керують великими стейками, де кожна пропущена епоха означає значні втрати;
  • мають клієнтські зобов'язання щодо доступності.

Для невеликих валідаторів з обмеженим бюджетом альтернативою є ретельне тестування оновлень на testnet та devnet (див. Як тестувати оновлення на testnet та devnet) та наявність перевіреної процедури відновлення з снапшота. Якщо оновлення все ж пішло не за планом, наступний крок — діагностика та виправлення (див. Як обробити невдале оновлення: діагностика та виправлення).

Джерела