Мы только что обновили DataStax Enterprise 3.2.2 до 4.5.1. Мы мигрировали с 3.2.2 -> 3.2.5 -> 4.0.3 -> 4.5.1, каждый раз следуя процедурам в документации и обновляя sstables после каждого обновления.
Сервера работают, ядро нормально принимает запросы.
Теперь, пытаясь избавиться от неоптимальных настроек, я пытаюсь перезагрузить ядро SolR с новым файлом solrconfig.xml, который завершается с ошибкой:
Текущий класс validation_class и найденный SolrType не совпадают для столбца: created_at
После некоторых исследований мы думаем, что создали устаревшую (бережливую) таблицу с использованием HTTP API, но каким-то образом также установили тип отображения данных на «2» (только для таблиц CQL3). Как мы можем решить эту проблему, не воссоздавая все с нуля?
При изменении типа отображения данных с «2» на «1» и публикации конфигурации и схемы через API я получаю следующее:
org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: ядро Solr peantus.oranges имеет dseTypeMappingVersion = 2, не может загрузить новую конфигурацию Solr с dseTypeMappingVersion = 1.
Трассировка стека для публикации solrconfig.xml с dseTypeMappingVersion = 2 выглядит следующим образом:
Следующая таблица была создана с использованием HTTP API поиска DSE.
Вот соответствующая выдержка из schema.xml:
cqlsh:peanuts> DESCRIBE TABLE oranges;
CREATE TABLE oranges (
key text,
"_docBoost" text,
category_id int,
category_name text,
city text,
country_code text,
created_at timestamp,
...
solr_query text,
text text,
user_id text,
week_of_year int,
year int,
PRIMARY KEY ((key))
) WITH COMPACT STORAGE AND
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.000000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.100000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
Мое текущее предположение состоит в том, что нам нужно изменить текущий solrconfig на сопоставление типа 1, поскольку это соответствует фактической настройке хранилища данных. Но как, если API не принимает POST?
<field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
<field name="created_at" type="date" indexed="true" stored="true" docValues="true" />
...
<field name="postal_code" type="string" stored="true" indexed="true"/>
<field name="country_code" type="string" stored="true" indexed="true"/>
<field name="city" type="string" stored="true" indexed="true"/>
<field name="latitude" type="float" indexed="true" stored="true"/>
<field name="longitude" type="float" indexed="true" stored="true"/>
<field name="text" type="text_general" indexed="true" stored="false" multiValued="true"/>
</fields>
....
<types>
<fieldType name="string" class="solr.StrField" sortMissingLast="true" />
<fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/>
<fieldType name="float" class="solr.TrieFloatField" precisionStep="0" positionIncrementGap="0"/>
<fieldType name="date" class="solr.TrieDateField" precisionStep="0" positionIncrementGap="0"/>
В качестве альтернативы я мог бы подумать о переходе на чистую таблицу CQL3, но это потребовало бы полной перегенерации данных с нуля, верно? Можно ли этого избежать?
Проблема заключается в вашем отображении типов в версии 2, которая ожидает TimestampType, в то время как Thrift использует DateType.
