Near. Распространенные ошибки ноды
Сленг
одноранговый узел - другая нода в сети валидаторов/нод, часто называется пиром
Мой узел ищет пиры в guildnet, testnet и mainnet. Почему?
Это известная проблема логгирования. Узел должен найти одноранговые узлы из той же сети. Это выводится в виде предупреждающего сообщения, поскольку нода проверяет наличие одноранговых нод из той же сети.
У меня нет нормального количества одноранговых узлов, и я вижу недостающие блоки?
Обычно узел должен находить от 12 до 15 пиров. Если количество одноранговых узлов вашей ноды невелико и вы видите отсутствующие блоки, вы можете попробовать перезапустить узел, чтобы сбросить свои одноранговые узлы.
У моей ноды недостаточно пиров, и некоторые пиры не работают.
Причина: Нода имеет среднее количество одноранговых узлов (12-15),
и x пиров не работает (например, во время обновления протокола, когда эти узлы обновляются с опозданием и выбрасываются), блоки могут быть пропущены.
Решение: Перезапустите свой узел и попытайтесь найти новых пиров. Плохо работающий одноранговый узел, который находится близко к вашему узлу, может привести к тому, что ваш узел пропустит блоки. Если одноранговый узел является вредоносным, вы можете рассмотреть возможность использования “черного списка": [“KEY@IP:24567 ”] в config.json, чтобы запретить одноранговый узел.
Мой узел не может найти ни одного пира или имеет один пир.
Причина 1: В зависимости от того, кто является первым одноранговым узлом, и если рядом с ним есть другие одноранговые узлы, узел не может найти больше одноранговых узлов.
Причина 2: Загрузочные узлы, определенные в config.json, могут быть заполнеными и не принимать больше подключений.
Решение: Вы можете потенциально добавить любой узел в config.json и использовать этот узел в качестве загрузочного узла, чтобы найти больше одноранговых узлов.
Причина 3: Подключен к узлу, который только что подключился к сети и не имеет обновленных одноранговых узлов.
Решение: Перезапустите ноду, чтобы найти другой одноранговый узел. Потенциально вы можете добавить любой узел в конфигурацию и использовать этот узел для поиска других одноранговых узлов.
Мой узел не может синхронизировать состояние или застрял в цикле состояния синхронизации.
Причина: Возможно, используется неправильный релиз nearcore.
Решение: Исправьте версию nearcore: https://github.com/near/nearcore/releases , и, пожалуйста, также проверьте подробную информацию о настройке узла.
Для шарднета нужно проверять акутальный коммит
Мой узел застрял в блоке.
Причина: Обычно это происходит в начале эпохи, когда время обработки блока может увеличиться.
Решение: Перезапуск узла обычно улучшает ситуацию.
Нода показывает "Mailbox closed" , когда нода выходит из строя.
Причина 1: поврежденное состояние
Решение: Существует проблема с базой данных. загрузите последний снимок(snapshot) и повторно синхронизируйте узел или синхронизируйте с вашего резервного узла, если у вас есть резервный узел.
Причина 2: Несоответствие Высоты Блока
Решение: Существует проблема с одноранговыми узлами. Нода забанила все одноранговые узлы на определенный период времени, и это связано с тем, что одноранговые узлы не были завершены должным образом:
https://github.com/near/nearcore/issues/5340 . Для оператора узла выполните поиск в журнале, чтобы увидеть, есть ли паника потока. Если возникнет паника, то сохраните свою базу данных из моментального снимка. Если паники нет, перезапустите свой узел.
Мой узел показывает "Почтовый ящик закрыт", когда узел запущен.
Мой узел банит ноды за мошенничество с высотой блока.
Причина: Возможно, ваше сетевое соединение работает медленно или нестабильно, или в центре обработки данных возникла проблема. Одноранговые узлы недостаточно быстро отправляют вам заголовки блоков.
Решение: если ваш узел работает нормально, ничего не делайте. Если ваши пиры все забанены, и переходите к следующему вопросу.
Все ваши одноранговые пользователи заблокированы из-за мошенничества с высотой блока.
Причина: Возможно, ваше одноранговое сетевое соединение работает медленно или нестабильно, или в вашем центре обработки данных возникла проблема. Если у вас часто 0 бит/с, это обычно указывает на проблему с подключением. Одноранговые узлы недостаточно быстро отправляют заголовки блоков вашего узла. Ваш узел может начать запрещать ваши одноранговые узлы из-за того, что ваш узел отстает (не синхронизируется).
Решение: Исправьте свое сетевое подключение. В config.json вы можете изменить значение ban_window на 1 секунду, чтобы избежать запрета одноранговых узлов.
Если ваш узел еще не синхронизирован, и вы отправили proposal, и узел показывает много различных ошибок (база данных не найдена, почтовый ящик закрыт и т.д.).
Причина: Ваш узел не синхронизирован. Пожалуйста, дождитесь полной синхронизации узла, прежде чем делать near proposal.
Решение: Полностью синхронизироваться, подождать 2 эпохи, а затем снова выполнить пинг.
Когда основной узел переключается на резервный узел, у резервной ноды возникают проблемы, она отстает и пропускает все блоки.
Причина: Эта проблема часто возникает из-за того, что в узле резервного копирования настроен неправильно config.json
Решение: Резервный узел должен отслеживать все сегменты(shards). Config.json по умолчанию во время инициализации имеет "tracked_shards": []. Пожалуйста, обновите config.json, чтобы включить "tracked_shards": [0] как в основной, так и в резервный узел.
Вы должны выполнить это обновление как для основного узла, так и для резервного узла.
Мой узел отправляет много запросов и потребляет много оперативной памяти.
Причина: Это наблюдается нечасто, но иногда случается. Узел начинает отправлять слишком много запросов и вызывает скачки использования памяти, затем он застревает через 10 минут, и у него заканчивается память.
Каковы причины поврежденного состояния узла?
- Позднее обновление из-за перехода на другую версию протокола
- Неправильная остановка узла. Узлу необходимо записывать последние обновления на диск, чтобы поддерживать базу данных в согласованном состоянии.
- Плохие снимки: Напиши в поддержку нира через Zendesk.
- Известная проблема миграции БД: Если вы остановите миграцию БД, узел окажется в поврежденном состоянии.
Мой узел показывает несогласованное состояние БД или БД Не найдена.
Причина: Несогласованное состояние БД, БД не найдена, обычно связаны с поврежденным состоянием (см. Выше).
Решение: В зависимости от серьезности проблемы узел может быть перезапущен для устранения несогласованного состояния. Если ситуация более серьезная, узлу, возможно, придется загрузить последний моментальный снимок и перезапустить его.
Мой узел пропускает блоки в начале эпох.
Причина: Обычно блоки могут быть пропущены в начале эпох из-за сборки мусора. Однако узел обычно догоняет во время эпохи и не выбивается.
Решение: Ожидание, пока узел попытается наверстать упущенное. Если вас выгнали, то попробуйте вернуться.
Каков типичный план восстановления после инцидента в основной сети с основным узлом и вторичным узлом
- Скопируйте файл node_key.json на вторичный узел
- Скопируйте файл validator_key.json на вторичный узел
- Остановите основной узел
- Остановите вторичный узел
- Перезапустите вторичный узел
Что происходит в процессе обновления ноды validator / RPC?
- Миграция БД (необязательно, если выпуск содержит миграцию БД)
- Поиск пиров
- Загрузка заголовков до 100%
- Синхронизация состояния
- Блоки загрузки
Что происходит в типичном процессе обновления архивного узла?
Поскольку архивному узлу нужны все блоки, он будет загружать блоки непосредственно после загрузки заголовков.
- Миграция БД (необязательно, если выпуск содержит миграцию БД)
- Поиск пиров
- Загрузка заголовков до 100%
- Блоки загрузки
Подписывайся на нас в телеграмм, чтобы получать больше информации о заработке в крипте.