Очень сложно синхронизировать Core Client с нуля

Недавно я запустил узел Core 15.1 с блокчейном на внешнем жестком диске, и мне было очень сложно полностью синхронизировать блокчейн. Проблема, с которой я постоянно сталкиваюсь, заключается в том, что (примерно в 90% моих попыток) синхронизация не завершается. Повреждение БД происходит в какой-то момент (обычно довольно поздно в игре, может быть, через 36 часов).

Я немного покопался в форумах и увидел, что я не первый пользователь, заметивший эту проблему. Питер Уилле упомянул, что он выполняет полную синхронизацию еженедельно, и она всегда работает, и поэтому он подозревает, что такие проблемы возникают из-за неоптимального оборудования.

Сначала это казалось очень разумным, потому что моя первая попытка была сделана с довольно старым карманным жестким диском на 400 гигабайт. Поэтому я поменял жесткие диски. К настоящему времени, примерно через 2 месяца, я пытался синхронизировать блокчейн с нуля около 20 или 30 раз, и только дважды мне удалось завершить процесс. Я сделал это на 4 разных типах жестких дисков, включая совершенно новый 1T Western Digital.

Можно сказать, что все 4 жестких диска, которые я использовал, «неоптимальны», но я бы возражал против этого, потому что

  • После завершения синхронизации узел работает нормально.
  • Я думаю, что желательно иметь возможность запускать полный узел на Raspberry Pi с жестким диском карманного размера (обратите внимание, что я запускаю узел на Raspberry Pi, но использую свой рабочий стол Linux для начальной синхронизации )

Теперь проблема, которая у меня здесь, заключается не столько в сбое во время синхронизации, сколько в том, что когда я перезапускаю клиент после сбоя, единственный вариант - начать с нуля (если я правильно понимаю, клиент не обязательно загружает все с поцарапать, но это не моя точка зрения) и снова синхронизировать с Genesis. В идеале я хотел бы, чтобы клиент продолжал синхронизацию с того места, куда он успешно попал, а не повторно синхронизировался с нуля при таких ошибках .

Мне интересно, необходима ли эта повторная синхронизация с нуля при ошибке . Я предполагаю, что повреждение происходит в одном (или нескольких) файлах в каталогах блоков или цепочек состояний. Если это так, то зачем синхронизировать с Genesis? Нельзя ли, скажем, удалить все файлы, опубликовать поврежденный файл и оттуда синхронизировать?

Если для такого поведения нет фундаментальной причины, я также был бы признателен за указатель на соответствующий код в клиенте.

Спасибо!!

Ответы (2)

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

Во время синхронизации ваш узел работает с нагрузкой, в сотни раз превышающей обычную: Учтите, что Биткойн существует уже более 3000 дней, но синхронизация завершится через день. Это имеет тенденцию подвергать маргинальному оборудованию. «субоптимальный» — не очень точное определение, лучше было бы «полностью сломанный».

USB-накопитель в целом печально известен тем, что вызывает коррупцию. Мало того, что сами диски часто ненадежны, многие люди часто страдают от проблем с USB-контроллерами и даже кабелями.

За счет еще нескольких гигабайт использования пространства биткойн-узлы могли бы периодически создавать резервные копии своего состояния, чтобы они могли более изящно восстанавливаться после повреждения... но затраты на это достаточно велики, поэтому выгоды не совсем очевидны. Тем более, что неисправное оборудование также может повредить резервные копии.

У меня есть два с половиной комментария из аналогичного опыта: RasPi — хорошее оборудование, но может быть не оптимальным устройством для полной ноды. Помимо множества ссылок на форуме здесь и на bitcointalk.org, я думаю, что все сводится к этим двум вопросам:

Процесс загрузки блокчейна на ваш компьютер требует большого количества операций ввода-вывода для диска. А поскольку RasPi имеет только USB-порт для подключения к диску, он в 10 раз медленнее, чем стандартный интерфейс к дисководу. В то время как мой стандартный интерфейс IDE работает со скоростью +20 мегабайт в секунду, мне было трудно достичь более 2 мегабайт в секунду через USB-устройство. И, конечно же, SSD работает еще быстрее...

Но это только часть записи данных на диск. Затем вам также нужно прочитать предыдущие сектора с диска, которые содержат несколько данных блокчейна с данными о предыдущих транзакциях. Здесь объем данных менее важен, но в игру вступают циклы дискового ввода-вывода. Это похоже на случайный поиск по диску, а также может замедлить процесс. Измерение загрузки ЦП показало +4.x, так что там было больше процессов, запрашивающих ввод-вывод, чем система могла обработать. С параметрами памяти тоже игрался, но безрезультатно. Ввод-вывод был ограничивающим фактором.

А еще есть мощность процессора RasPi. Я узнал, что мой RasPi довольно хорошо и стабильно загружал блокчейн до июля/августа 2017 года, а затем время от времени начал задыхаться. Это как раз то время, когда блоки заполнялись все больше и больше. И я понимаю, что загрузка полного блока означает, что нужно проверить очень много данных, добавляя нагрузку на RasPi. Что касается операционной системы, мне больше удалось загрузить блокчейн с помощью Linux. Windows была просто недостаточно надежной. Но тем не менее мне потребовалось более 3 недель на RasPi2, чтобы загрузить блокчейн.

Что я тогда сделал: у меня есть три разных Macintosh, два из которых оснащены SSD и Intel Core Duo и 4 ГБ ОЗУ (таким довольно старым, около +6 лет). У этих SSD-систем не было проблем с загрузкой блокчейна, им по-прежнему требовалось от 2 до 3 дней.

Кстати: я наблюдал точно такие же проблемы с Ethereum и RasPi. Так что мне кажется, что у RasPi есть свои ограничения, когда дело доходит до высоких нагрузок. Я ничего не отлаживал, но похоже, что RasPi теряет некоторые прерывания при высокой нагрузке, что приводит к ошибкам записи данных на диск. Кроме того, я не использовал охлаждающее устройство, поэтому процессор, безусловно, достиг своей максимальной температуры при расчете всех sha256, base58 и sigs.

Чтобы обойти это, я скопировал загруженный блокчейн с Mac с SSD на RasPi, и тогда он снова работал как часы. Подсказка: я проводил эти тесты с RasPi2 до ноября 2017 года, модель type3 должна быть немного быстрее, но не по величине.

Итак, когда вы говорите, что загружаете первоначальную цепочку блоков со своего ПК, жесткий диск все еще подключен к USB-накопителю? Вы пробовали использовать локальный диск, а затем выполнить синхронизацию с RasPi? Может стоит проверить. Я обнаружил, что пропускная способность интернет-соединения не является ограничивающей проблемой, пока вы загружаете блокчейн...

Спасибо за развернутый ответ. Как я уже сказал, я не использую RasPi для синхронизации по указанным вами причинам, а скорее синхронизирую напрямую с USB-накопителем на ПК. Я предполагаю, что меня больше всего интересует, действительно ли необходимо синхронизировать весь путь от Genesis, когда во время синхронизации возникает ошибка, и можно ли как-то продолжить синхронизацию с «последней точки, до которой она синхронизировалась правильно».
Ах, да, понятно... Я искал то же самое, но не мог найти способ, как это сделать. И я не смотрел в код...
вы наверняка уже видели ответы на bitcointalk. Для остальных читателей здесь: bitcointalk.org/index.php?topic=3286587.0 .
Только что перешел ветку в bitcointalk: bitcointalk.org/index.php?topic=3307283.0 (от chow: используйте RPC-команду rescanblockchain, которая принимает параметр высоты)