Диск цел, но отвалился на некоторое время - около суток, аудиты начали падать, на одном из спутников произошла дисквалификация, на др. упали значения. Возможно ли восстановить?
Hi @bmr,
Yes, it should be possible to recover. If you keep the drive/disk connected and the node online the other satellites should go back to 100% audit as no data should be lost, it was just unavailable for a short time.
The disqualified satellite won’t recover.
1 Like
Да как то совсем давно в самом начале, не помню при каких обстоятельствах, восстанавливали ноду. Если файлы базы данных на др диске каким образом можно реализовать , в подобных ситуациях, чтобы било не по аудиту , а по аптайму ? Причем сертификаты были на отвалившемся диске, они проверяются только при запуске? Или периодически тоже проверяется?? Если не восстановить уже дисквалифицированный спутник то можно удалить папочку с его названием?
Google translate, might be doing a disservice. Is the drive failed or just temporarily disconnected? If the drive is failed then there is no recovery and the node is finished. If it was only disconnected for a short time then the non-disqualified satellites should recover.
The database files only relate to the node statistics, they are not required for the customer data.
The certificate check and the storagenode data folder/directory check is only on startup. If the disk with the customer data is disconnected after the node is running, the node won’t stop it will only fail audits.
Where there is a disqualified satellite you can remove all the customer data for that satellite without additional penalty or consequence.
Я так потерял несколько нод. Диск отвалился, а нода вместо отключения висела онлайн и сливала аудиты. На тех нодах, где отвалился и saltlake и europe-north-1, но остались остальные спутники я сделал Graceful exit и пересоздал ноды с нуля. На одной ноде вылетел только спутник europe-north-1, ее оставил, аудиты выправились, работает дальше.
Identity проверяется только при старте. Эту папку желательно поместить на диск с данными и использовать оттуда, потому что identity без данных бесполезна - она будет дисквалифицирована практически моментально, впрочем данные без identity тоже бесполезны - с новой identity они будут просто медленно удалены (может занять месяцы).
Дисквалификация постоянная и восстановлению не подлежит, если audit score меньше 60%.
Вы можете удалить данные дисквалифицировавшего сателлита, однако на ваш страх и риск. Соответствие папок сателлитам можно посмотреть тут:
Я бы пока не торопился удалять данные.
This is not like this now. We create a special file in the data directory during setup, it’s called storage-dir-verification, it contains encoded NodeID. So, if it would not be available or not readable or the NodeID is different - the node will crash.
Раньше действительно было так, что если диск отключался во время работы узла, узел продолжал работать и проваливать аудиты (данных-то больше нет).
Сейчас мы создаём во время установки (и только во время неё!) специальный файл storage-dir-verification в папке с данными, он содержит закодированный NodeID. Если этот файл перестаёт быть доступным или не читается или не совпадает NodeID - узел должен падать с ошибкой.
Тоже самое касается папки с данными:
Кстати, ради этого файла и папок установка теперь отдельный шаг. Он необходим в docker версии (SETUP=true) и в binary версии (storagenode setup) и должен выполняться ровно один раз за всё время существования узла.
@bmr А вы используете docker или binary (Windows GUI, Linux GUI)?
Если docker - как вы монтируете диски в контейнер? -v или --mount?
Ноды были весьма старые и отдельного шага установки не было.
Как можно создать storage-dir-verification для существующей старой ноды?
PS Проверил, на старых нодах тоже есть такой файл. Жаль, что не всегда эта защита срабатывает.
windows gui, в папке storage файл storage-dir-verification имеется, где упали аудиты, там почти везде восстановились до 100 %, кроме дисквалифицированного естественно. То есть если правильно работает нода, то при отвале директории с данными нода должна вырубиться и падать аптайм? если да, то не работает эта функция. В логах в режиме инфо про проваленные аудиты ничего нет.
Она работает. Проверка осуществляется каждые 30 секунд по умолчанию.
На всех узлах и старых и новых этот файл должен быть. Перед тем как добавили опцию SETUP=true, мы выпустили версию, которая создаёт этот файл молча в ходе обычного запуска. Через несколько версий мы убрали авто установку и добавили отдельный шаг.
Так что у вас эта защита тогда ещё не существовала
Да, узел должен останавливаться с ошибкой, что файл или директория недоступны.
Какие есть ошибки в логе дисквалифицированного узла?
2021-08-05T09:53:01.064+0500 ERROR piecestore download failed "{""Piece ID"": ""AGG2PNYANQFNHCYHENR7VW22BEXGVGQPJNFP4A4E2BHZBFYUUWOQ"", ""Satellite ID"": ""12tRQrMTWUWwzwGh18i7Fqs67kmdhH9t6aToeiwbo5mfS2rUmo"", ""Action"": ""GET_AUDIT"", ""error"": ""pieces error: filestore error: unable to open \""T:\\\\v3\\\\storage\\\\blobs\\\\arej6usf33ki2kukzd5v6xgry2tdr56g45pp3aao6llsaaaaaaaa\\\\ag\\\\g2pnyanqfnhcyhenr7vw22bexgvgqpjnfp4a4e2bhzbfyuuwoq.sj1\"": The request could not be performed because of an I/O device error."", ""errorVerbose"": ""pieces error: filestore error: unable to open \""T:\\\\v3\\\\storage\\\\blobs\\\\arej6usf33ki2kukzd5v6xgry2tdr56g45pp3aao6llsaaaaaaaa\\\\ag\\\\g2pnyanqfnhcyhenr7vw22bexgvgqpjnfp4a4e2bhzbfyuuwoq.sj1\"": The request could not be performed because of an I/O device error.\n\tstorj.io/storj/storage/filestore.(*Dir).Open:279\n\tstorj.io/storj/storage/filestore.(*blobStore).Open:75\n\tstorj.io/storj/storagenode/pieces.(*Store).Reader:262\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Download:530\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func2:217\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:102\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:60\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:95\n\tstorj.io/drpc/drpcctx.(*Tracker).track:51""}"
Такие ошибки должны учитываться как “Unknown”. И они должны приводить к приостановке (“suspension”), а не дисквалификации.
Написал команде. Пока что выглядит как баг.
Создал баг. Не удаляйте данные узла и identity пожалуйста и держите узел online.
Весь лог файл не нужен?
Да, пришлите пожалуйста в личку через transfer.sh только пожалуйста упакуйте перед отправкой
Ещё вопрос - не разделяли ли хранение? Например - blobs на одном диске, базы на другом, заказы на третьем?
Здравствуйте!
В логах содержаться ошибки audit, такие как
2021-08-05T09:53:01.064+0500 ERROR piecestore download failed "{""Piece ID"": ""AGG2PNYANQFNHCYHENR7VW22BEXGVGQPJNFP4A4E2BHZBFYUUWOQ"", ""Satellite ID"": ""12tRQrMTWUWwzwGh18i7Fqs67kmdhH9t6aToeiwbo5mfS2rUmo"", ""Action"": ""GET_AUDIT"", ""error"": ""pieces error: filestore error: unable to open \""T:\\\\v3\\\\storage\\\\blobs\\\\arej6usf33ki2kukzd5v6xgry2tdr56g45pp3aao6llsaaaaaaaa\\\\ag\\\\g2pnyanqfnhcyhenr7vw22bexgvgqpjnfp4a4e2bhzbfyuuwoq.sj1\"": The request could not be performed because of an I/O device error."", ""errorVerbose"": ""pieces error: filestore error: unable to open \""T:\\\\v3\\\\storage\\\\blobs\\\\arej6usf33ki2kukzd5v6xgry2tdr56g45pp3aao6llsaaaaaaaa\\\\ag\\\\g2pnyanqfnhcyhenr7vw22bexgvgqpjnfp4a4e2bhzbfyuuwoq.sj1\"": The request could not be performed because of an I/O device error.\n\tstorj.io/storj/storage/filestore.(*Dir).Open:279\n\tstorj.io/storj/storage/filestore.(*blobStore).Open:75\n\tstorj.io/storj/storagenode/pieces.(*Store).Reader:262\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Download:530\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func2:217\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:102\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:60\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:95\n\tstorj.io/drpc/drpcctx.(*Tracker).track:51""}"
Такие ошибки больше не приводят к suspension, они приводят к дисквалификации.
Suspension в audit временная мера, пока все ошибки не будут идентифицированы и классифицированы.
Такие ошибки, к сожалению, трактуются как “кусочек повреждён” и снижают оценку аудита.
Ваш лог содержит довольно много таких ошибок, поэтому дисквалификация была неминуема.
К сожалению, файл storage-dir-verification был доступен, поэтому узел так и не остановился.
Я проверил на VM Windows 10, если диск пропадает или отключается, узел падает с ошибкой
2021-08-14T11:57:49.938+0300 ERROR services unexpected shutdown of a runner {"name": "piecestore:monitor", "error": "piecestore monitor: error verifying location and/or readability of storage directory: open D:\\storagenode6\\storage-dir-verification: The system cannot find the path specified.", "errorVerbose": "piecestore monitor: error verifying location and/or readability of storage directory: open D:\\storagenode6\\storage-dir-verification: The system cannot find the path specified.\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1.1:131\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1:128\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}
В вашем случае файл был по-прежнему доступен, и узел продолжал работать.
Как безопасно удалить данные дисквалифицированного спутника salltlake в частности ?
Здесь соответствие папок в blobs сателлитам:
Здесь как использовать свой список доверенных сателлитов:
Continuing the discussion from RE: Дисквалификация ноды на одном саттелите:
Вполне возможно что они целые, однако спутник больше не будет проверять ваш узел после падения репутации ниже 60%.
Полную проверку проводить очень дорого - сателлит должен скачать все данные с узла по цене аудита, потом проверить и восстановить на другие узлы (то есть не на ваш) если что-то повреждено (в этом случае скачать ещё 29 кусочков по цене восстановления с других узлов, восстановить до 80 и распределить по другим узлам сети недостающие 51 кусочек). В этом случае ещё пострадают и ни в чём не повинные 50 операторов (кусочки с их узлов будут удалены).
В ходе полного аудита может оказаться, что повреждённых кусочков на вашем узле слишком много и узел будет гарантированно дисквалифицирован за это. Сумма проверки и сумма за ремонт могут превысить held amount на этом сателлите для этого узла.
Сателлиту дешевле дисквалифицировать узел и заниматься восстановлением данных только когда это необходимо (количество здоровых кусочков упадёт ниже порога) по той же цене, что аудит, но с результатом - восстановленными данными.