Cannot index into solr 8.1.1

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Cannot index into solr 8.1.1

Bhuvanesh
Hi team,

Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud Solr
6.6.2 which is in use. All configurations and schema files are exactly
alike, but when I try to index the same documents Solr throws *cannot
change field "FIELD_NAME" from* *index options=DOCS_AND_FREQS_AND_POSITIONS
to inconsistent index options=DOCS* for a specific field which is of type
*string*. It is a required field so cannot be omitted.

For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
change docValues type from SORTED_NUMERIC to SORTED for field
"ANOTHER_FIELD_NAME"* to the field of type *string.*

This is not existing solr upgrade, Solr 8.1.1 setup is completely new from
scratch and I am simply indexing the same data which we are using now with
solr 6.6.2

Both field type definitions are:

<field name="FIELD_NAME" type ="string" required=true>

<field name="ANOTHER_FIELD_NAME" type ="string" required=true>


*Note:* It is indexing perfectly in the existing Solr i.e., 6.6.2


Kind regards,
Bhuvaneshwar Venkatraman
Reply | Threaded
Open this post in threaded view
|

Re: Cannot index into solr 8.1.1

Shawn Heisey-2
On 9/16/2019 10:18 AM, Bhuvanesh wrote:

> Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud Solr
> 6.6.2 which is in use. All configurations and schema files are exactly
> alike, but when I try to index the same documents Solr throws *cannot
> change field "FIELD_NAME" from* *index options=DOCS_AND_FREQS_AND_POSITIONS
> to inconsistent index options=DOCS* for a specific field which is of type
> *string*. It is a required field so cannot be omitted.
>
> For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
> change docValues type from SORTED_NUMERIC to SORTED for field
> "ANOTHER_FIELD_NAME"* to the field of type *string.*
>
> This is not existing solr upgrade, Solr 8.1.1 setup is completely new from
> scratch and I am simply indexing the same data which we are using now with
> solr 6.6.2

Those errors indicate that there is an existing index that was built
with a different schema, and the current index is not compatible with
the schema you have now.

You're saying that you're indexing from scratch, but the error messages
are indicating otherwise.

It's not possible to use an index from Solr 6 in Solr 8, and the errors
would be entirely different if you tried.

This problem looks like you indexed some stuff in version 8, then
changed the schema, and are trying to index more.  But your problem
description seems to contradict this theory, so I'm not sure what to think.

The solution to these errors is to entirely delete all of the
$CORE/data/index directories from each index core related to the
collection, restart Solr or reload the collection, and reindex again
from scratch.

Thanks,
Shawn
Reply | Threaded
Open this post in threaded view
|

Re: Cannot index into solr 8.1.1

Bhuvanesh
Hi Shawn,

Thanks for your reply.

The core is used to test the solr setup by creating a trial collection. But
other than that every collection created are exactly the same as existing
one. I don't think this would create a problem, please brief me if it is
otherwise.

Thanks and regards,
Bhuvaneshwar Venkatraman

On Mon, Sep 16, 2019, 9:59 PM Shawn Heisey <[hidden email]> wrote:

> On 9/16/2019 10:18 AM, Bhuvanesh wrote:
> > Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud
> Solr
> > 6.6.2 which is in use. All configurations and schema files are exactly
> > alike, but when I try to index the same documents Solr throws *cannot
> > change field "FIELD_NAME" from* *index
> options=DOCS_AND_FREQS_AND_POSITIONS
> > to inconsistent index options=DOCS* for a specific field which is of type
> > *string*. It is a required field so cannot be omitted.
> >
> > For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
> > change docValues type from SORTED_NUMERIC to SORTED for field
> > "ANOTHER_FIELD_NAME"* to the field of type *string.*
> >
> > This is not existing solr upgrade, Solr 8.1.1 setup is completely new
> from
> > scratch and I am simply indexing the same data which we are using now
> with
> > solr 6.6.2
>
> Those errors indicate that there is an existing index that was built
> with a different schema, and the current index is not compatible with
> the schema you have now.
>
> You're saying that you're indexing from scratch, but the error messages
> are indicating otherwise.
>
> It's not possible to use an index from Solr 6 in Solr 8, and the errors
> would be entirely different if you tried.
>
> This problem looks like you indexed some stuff in version 8, then
> changed the schema, and are trying to index more.  But your problem
> description seems to contradict this theory, so I'm not sure what to think.
>
> The solution to these errors is to entirely delete all of the
> $CORE/data/index directories from each index core related to the
> collection, restart Solr or reload the collection, and reindex again
> from scratch.
>
> Thanks,
> Shawn
>
Reply | Threaded
Open this post in threaded view
|

Re: Cannot index into solr 8.1.1

Erick Erickson
99.9% sure that if you look closely, you’ll find that these fields are inappropriately defined. What may have happened is that there are tighter checks in Solr 8 that throw errors where the contradictory definitions were silently ignored. For instance you report one error:

SORTED_NUMERIC to SORTED for field "ANOTHER_FIELD_NAME" to the field of type string.

Any mention of SORTED_NUMERIC with a field type of string means something is very wrong with the definition. Usually, this is a function of changing the definition without starting with a new collection. So are you sure that when you create a collection to test you completely blow the old collection away?

And if this is using “schemaless” mode, it would mean that the type inferred for the first document with a particular field is incorrect, which is why there’s a warning printed out about disabling schemaless mode.

Best,
Erick



> On Sep 16, 2019, at 1:15 PM, Bhuvanesh <[hidden email]> wrote:
>
> Hi Shawn,
>
> Thanks for your reply.
>
> The core is used to test the solr setup by creating a trial collection. But
> other than that every collection created are exactly the same as existing
> one. I don't think this would create a problem, please brief me if it is
> otherwise.
>
> Thanks and regards,
> Bhuvaneshwar Venkatraman
>
> On Mon, Sep 16, 2019, 9:59 PM Shawn Heisey <[hidden email]> wrote:
>
>> On 9/16/2019 10:18 AM, Bhuvanesh wrote:
>>> Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud
>> Solr
>>> 6.6.2 which is in use. All configurations and schema files are exactly
>>> alike, but when I try to index the same documents Solr throws *cannot
>>> change field "FIELD_NAME" from* *index
>> options=DOCS_AND_FREQS_AND_POSITIONS
>>> to inconsistent index options=DOCS* for a specific field which is of type
>>> *string*. It is a required field so cannot be omitted.
>>>
>>> For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
>>> change docValues type from SORTED_NUMERIC to SORTED for field
>>> "ANOTHER_FIELD_NAME"* to the field of type *string.*
>>>
>>> This is not existing solr upgrade, Solr 8.1.1 setup is completely new
>> from
>>> scratch and I am simply indexing the same data which we are using now
>> with
>>> solr 6.6.2
>>
>> Those errors indicate that there is an existing index that was built
>> with a different schema, and the current index is not compatible with
>> the schema you have now.
>>
>> You're saying that you're indexing from scratch, but the error messages
>> are indicating otherwise.
>>
>> It's not possible to use an index from Solr 6 in Solr 8, and the errors
>> would be entirely different if you tried.
>>
>> This problem looks like you indexed some stuff in version 8, then
>> changed the schema, and are trying to index more.  But your problem
>> description seems to contradict this theory, so I'm not sure what to think.
>>
>> The solution to these errors is to entirely delete all of the
>> $CORE/data/index directories from each index core related to the
>> collection, restart Solr or reload the collection, and reindex again
>> from scratch.
>>
>> Thanks,
>> Shawn
>>