Поиск и устранение повреждений данных

Elasticsearch ожидает, что данные, которые он считывает с диска, точно соответствуют данным, которые он ранее записал. Если он обнаружит, что данные на диске отличаются от записанных, то он сообщит об этом, например, с помощью исключения:

Обычно эти исключения возникают из-за несоответствия контрольных сумм. Большая часть данных, записываемых Elasticsearch на диск, сопровождается контрольной суммой, вычисленной с помощью простого алгоритма CRC32, который быстро вычисляется и хорошо обнаруживает случайные повреждения, которые могут возникнуть при использовании неисправного хранилища. Несоответствие контрольной суммы CRC32 определенно указывает на неисправность, хотя, конечно, совпадение контрольной суммы не доказывает отсутствие повреждений.

Проверка контрольной суммы является ресурсоемкой операцией, поскольку она включает чтение каждого байта файла, что требует значительных усилий и может вытеснить более полезные данные из кэша файловой системы, поэтому системы обычно не проверяют контрольную сумму файла очень часто. Именно поэтому исключение повреждения данных возникает только при возникновении необычных ситуаций. Например, повреждения часто обнаруживаются во время слияний, перемещений фрагментов и создания снимков. Это не означает, что эти процессы вызывают повреждения: это примеры редких случаев, когда требуется чтение всего файла. Elasticsearch использует этот случай для проверки контрольной суммы одновременно, и именно тогда обнаруживается и сообщается о повреждении. Это не указывает на причину повреждения или время его возникновения. Повреждения могут оставаться незамеченными в течение многих месяцев.

Файлы, составляющие индекс Lucene, записываются последовательно от начала до конца и никогда не изменяются или перезаписываются. Такая схема доступа означает, что вычисление контрольной суммы очень простое и может происходить в режиме реального времени при первоначальной записи файла, а также делает очень маловероятным, что неверная контрольная сумма вызвана ошибкой пользовательского пространства в момент записи файла. Часть Elasticsearch, которая вычисляет контрольную сумму, проста в реализации, широко используется и очень хорошо протестирована, поэтому вы можете быть уверены, что несоответствие контрольной суммы действительно указывает на то, что данные, считанные с диска, отличаются от данных, которые Elasticsearch ранее записал.

Если заголовок файла поврежден, Elasticsearch, возможно, не сможет определить, как начать чтение файла, что может привести к исключению, например:

Также возможно, что Elasticsearch сообщит о повреждении, если необходимый файл отсутствует полностью, с исключением, например:

Файлы, составляющие индекс Lucene, записываются полностью до их использования. Если для восстановления индекса после перезапуска требуется файл, то ваша система хранения ранее подтвердила Elasticsearch, что этот файл был надёжно синхронизирован с диском. В Linux это означает, что системный вызов fsync() завершился успешно. Иногда Elasticsearch сообщает о повреждении индекса, потому что необходимый для восстановления файл отсутствует или он существует, но был усечён или отсутствует его подпись. Это может указывать на то, что ваша система хранения неправильно обрабатывает надёжные записи.

Существует множество возможных объяснений того, почему Elasticsearch обнаруживает повреждения в вашем кластере. Базы данных, такие как Elasticsearch, генерируют сложную рабочую нагрузку ввода-вывода, которая может выявить скрытые инфраструктурные проблемы, которые другие тесты могут пропустить. Elasticsearch известно о следующих проблемах, которые отображаются как повреждение файлов:

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

Чтобы исключить Elasticsearch как источник повреждения данных, сгенерируйте рабочую нагрузку ввода-вывода, используя что-то другое, чем Elasticsearch, и проверьте наличие ошибок целостности данных. В Linux инструменты fio и stress-ng могут генерировать сложные рабочие нагрузки ввода-вывода и проверять целостность данных, которые они записывают. Используйте версию 0.12.01 или более позднюю версию stress-ng, так как более ранние версии не имеют достаточных проверок целостности. Проверьте, что надёжные записи сохраняются после сбоев питания, используя сценарий, такой как diskchecker.pl. В качестве альтернативы, используйте инструмент, такой как strace, чтобы наблюдать последовательность системных вызовов, которые Elasticsearch делает при записи данных, и подтвердить, что эта последовательность не объясняет сообщения о повреждении.

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