Появилась идея сделать backup-ноду, чтоб в случае падения основной ноды, на лету переключать генерацию блоков на резервный сервер.
Если алгоритм моих действий верен, то попробую этот процесс автоматизировать и выложу готовый скрипт.
Алгоритм действий
Что я сделал?
Имея активную ноду (я в данный момент активный делегат) я запустил еще одну ноду на отдельном сервере, в cli_wallet сделал import_key от своего аккаунта xtar, сгенерировал с помощью команды suggest_brain_key новый набор ключей и прописал private brain key в config.ini.
После запуска golosd начал периодически выдавать резонное сообщение
Not producing block for xtar because I don't have the private key for GLS6rfMKdTTd...
Сделал update_witness с новым ключом (brain public key резервного сервера). Словил 1 missed блок, после чего резервный сервер успешно начал генерировать блоки.
Сделал update_witness с ключем от основного сервера, missed не словил и генерация успешно переключилась на основную ноду.
Итоги и вопрос
У меня получилось на лету переключать активного витнесса с ноды на ноду.
Вопрос. В вики указано:
Вы не должны заводить ноду свидетеля с той же учетной записью, your-account-name, на более чем одну систему steemd. Если это произойдет, то обе системы steemd произведут блок одновременно. Другие узлы сети увидят это двойное подписание и представят доказательство в сеть, что позволит им претендовать на остаток средств на вашей учетной записи.
Хотел уточнить. Мне крупно повезло или речь идет о двух нодах с идентичным набором brain-ключей?
Можно ли действовать по данному алгоритму? Или это чревато последствиями?
Я так понимаю, что речь идет о двух нодах с одинаковыми ключами, т.е. если ты использовал два разных ключа, то просто выключил одну ноду и включил другую.
Тогда в Вики надо так и написать. Сейчас там только про your-account-name.
Единственный нюанс, насколько я понимаю, шаг с import_key был совершенно не нужен. suggest_brain_key просто создает набор ключей от балды никак не связаных с имеющимися или импортироваными ключами. В остальном все ок, правда не понятно почему потерялся блок - но возможно просто реально нужно сразу после генерации блока делать, что-бы успело принять блок с изменением ид ибо видимо если прям перед созданием блока переключиться происходит его потеря.
Блок потерялся в момент между тем, когда я отправил update_witness и ожиданием ответа от сервера.
Я правильно понимаю, что при этом посылал команду на смену ключа ты на резервном сервере?
Да, на резервном.
Почему это не нужен? Иначе он не смог бы в cli_wallet вводить команды своего аккаунта xtar.
Т.е. если надо будет переключиться, он не сможет сделать update_witness
В этом плане да, но кстати интересно где правильнее посылать команду на смену ключа - не резервном сервере или на текущем? По логике быстрее должно сработать на резервном.
Вообще, если основной вдруг падает, то только на резервном и можно будет ключ поменять. Получается, что на резервном должен быть скрипт, который отслеживает работоспособность основного сервера и в случае его падения меняет ключ витнеса.
Или на любом другом если их еще больше - может отдельный сервер заниматься мониторингом всех остальных - там можно сделать более надежно.
Но получается, что если основной сервер падает, то надо делать update_witness для переключения на резервный. Можно ли как-то автоматизировать переключение?
В принципе уже есть готовые скрипты от @jesta - но не очень легко настраиваемые:
https://github.com/aaroncox/witness-failover
Да, возможно сделать скрипт.