После еще одного исследования, вот что я обнаружил:
Ответ на часть 1:
InfluxDB использует систему, которую они называют «шардингом» - хотя я не знаю специфики, я знаю, что данные из одного измерения / таблицы могут храниться в нескольких разных «шардах».
В соответствии с документацией InfluxDB, типы полей могут различаться между этими шардами, в пределах одного поля, в одной и той же таблице.
Ответ на часть 2:
Чтобы исправить это, предлагаемый в настоящее время ответ состоит в создании новой таблицы, загрузке всех данных и повторной вставке, обеспечивая при этом правильность типов вставляемых данных.
Если у вас есть тег, который изменил тип и стал полем, это может быть особенно трудно исправить, ссылка выше не решает эту проблему. Чтобы делать выборки только по тегу или полю, вы можете использовать tag_name::tag или field_name::field в операторе выбора.
Предложение GROUP BY *, предложенное в ссылке, требуется для сохранения тегов, но, похоже, вызывало проблемы при его использовании.
Мое текущее решение - это PHP-скрипт, который использует curl, загружает точки, разбивает их на части, затем повторно вставляет точки в новую таблицу, гарантируя, что каждая вставляемая точка приведена к новому унифицированному типу и правильно вставлена .
Лучший способ остановить будущие проблемы - просто не иметь их. Я искал, как во всех случаях блокировать типы полей для всех сегментов для конкретной таблицы измерений.
К сожалению, кажется невозможным гарантировать 100% согласованность типов для всех текущих и будущих сегментов. «Не делайте ошибок, потому что это действительно трудно очистить», похоже, является способом работы InfluxDB.