You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by Paul Ryder <pa...@greenwaymediatech.com> on 2023/02/28 09:20:39 UTC
Solr Replication
All,
I see warnings in the Solr master replication like this
2023-02-24 18:10:40.964 WARN (qtp156856360-13173) [ x:Fred_apis_responses_index] o.a.s.h.ReplicationHandler Exception while writing response for params: generation=394103&qt=/replication&file=segments_8g3b&checksum=true&compression=true&wt=filestream&command=filecontent => java.nio.file.NoSuchFileException: E:\Solr8.1.1\Fred_apis_responses_index\data\restore.20221207055103765\segments_8g3b
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
And warnings/errors on Slave servers such as
File _exa0_Lucene50_0.tim did not match. expected checksum is 1661977412 and actual is checksum 116298600. expected length is 4648 and actual length is 4145
Error removing directory E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425 before core close:java.io.IOException: Unable to delete file: E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425\_ex9o.cfs
Solr 8.1.1 on Java 8 - Windows
Can anyone shed light on what is happening?
Thanks in advance, Paul
RE: Solr Replication
Posted by Paul Ryder <pa...@greenwaymediatech.com>.
Hi Shawn, brilliant answer...
-----Original Message-----
From: Shawn Heisey <el...@elyograg.org>
Sent: 07 March 2023 00:46
To: users@solr.apache.org
Subject: Re: Solr Replication
On 3/5/2023 7:45 AM, Paul Ryder wrote:
> Hi Shawn, thanks for your reply… would you happen to know if Solr
> 8.8.2 is compatible with zookeeper 3.6.4? there is a bug in 3.6.2
> (false eof messsge) that’s screwing up our automation…
8.8.2 is nearly two years old. If there's some reason you can't go with 9.1.1, then you should at least use the latest 8.x, which is 8.11.2.
The announce date for 8.11.2 was June 17 2022, less than a year ago.
Solr 8.8.2 includes version 3.6.2 of the ZK client. Which means it is guaranteed compatible with server versions from 3.5.x through 3.7.x.
Solr 8.11.2 also includes ZK client version 3.6.2.
Solr 9.1.1 includes version 3.8.1 of the ZK client, the latest version currently available. Which means it is guaranteed compatible with server versions from 3.7.x through 3.9.x, though 3.9.x has not yet been released. The latest stable version of ZK is 3.7.1.
The ZK project guarantees compatibility if the version number of the client and server differ by one minor version and are in the same major version. In a version of X.Y.Z the minor version is Y. They also guarantee that a new major version will be compatible with the last release in the prior major version. So when they release 4.0.0, it will be compatible with whatever 3.x version was the most recent at the time of its release.
A given version might be compatible with a wider range of versions than what is described here, but those are the criteria for GUARANTEED compatibility.
Thanks,
Shawn
Re: Solr Replication
Posted by Shawn Heisey <el...@elyograg.org>.
On 3/5/2023 7:45 AM, Paul Ryder wrote:
> Hi Shawn, thanks for your reply… would you happen to know if Solr 8.8.2 is compatible with zookeeper 3.6.4? there is a bug in 3.6.2 (false eof messsge) that’s screwing up our automation…
8.8.2 is nearly two years old. If there's some reason you can't go with
9.1.1, then you should at least use the latest 8.x, which is 8.11.2.
The announce date for 8.11.2 was June 17 2022, less than a year ago.
Solr 8.8.2 includes version 3.6.2 of the ZK client. Which means it is
guaranteed compatible with server versions from 3.5.x through 3.7.x.
Solr 8.11.2 also includes ZK client version 3.6.2.
Solr 9.1.1 includes version 3.8.1 of the ZK client, the latest version
currently available. Which means it is guaranteed compatible with
server versions from 3.7.x through 3.9.x, though 3.9.x has not yet been
released. The latest stable version of ZK is 3.7.1.
The ZK project guarantees compatibility if the version number of the
client and server differ by one minor version and are in the same major
version. In a version of X.Y.Z the minor version is Y. They also
guarantee that a new major version will be compatible with the last
release in the prior major version. So when they release 4.0.0, it will
be compatible with whatever 3.x version was the most recent at the time
of its release.
A given version might be compatible with a wider range of versions than
what is described here, but those are the criteria for GUARANTEED
compatibility.
Thanks,
Shawn
Re: Solr Replication
Posted by Paul Ryder <pa...@greenwaymediatech.com>.
Hi Shawn, thanks for your reply… would you happen to know if Solr 8.8.2 is compatible with zookeeper 3.6.4? there is a bug in 3.6.2 (false eof messsge) that’s screwing up our automation…
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Shawn Heisey <el...@elyograg.org>
Sent: Saturday, March 4, 2023 6:09:23 AM
To: users@solr.apache.org <us...@solr.apache.org>
Subject: Re: Solr Replication
On 2/28/2023 2:20 AM, Paul Ryder wrote:
> All,
>
> I see warnings in the Solr master replication like this
>
> 2023-02-24 18:10:40.964 WARN (qtp156856360-13173) [ x:Fred_apis_responses_index] o.a.s.h.ReplicationHandler Exception while writing response for params: generation=394103&qt=/replication&file=segments_8g3b&checksum=true&compression=true&wt=filestream&command=filecontent => java.nio.file.NoSuchFileException: E:\Solr8.1.1\Fred_apis_responses_index\data\restore.20221207055103765\segments_8g3b
> at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
Not sure why a file that is expected to be there isn't there.
> And warnings/errors on Slave servers such as
>
> File _exa0_Lucene50_0.tim did not match. expected checksum is 1661977412 and actual is checksum 116298600. expected length is 4648 and actual length is 4145
This sounds like a file got corrupted. Something changed it.
> Error removing directory E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425 before core close:java.io.IOException: Unable to delete file: E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425\_ex9o.cfs
>
> Solr 8.1.1 on Java 8 - Windows
Windows can't delete a file that something has open in ANY mode. Linux
and other similar operating systems have no trouble deleting open
files. Software like Solr just works better on most open source
operating systems than on Windows.
The question comes down to why that file is open when Lucene (the
central Search API used by Solr) tries to delete it. This can be caused
by antivirus software, backup software, or several other possibilities.
I can see antivirus software causing all of the problems you have
described. You should exclude the place Solr stores its indexes from
scanning by antivirus software.
In addition to problems that running on Windows can cause, there is the
fact that Solr 8.1.1 is nearly four years old and is basically
unsupported. Any problems you find would need to be demonstrated as
happening in the latest Solr version, and due to a bug in Solr, not some
aspect of the environment.
Thanks,
Shawn
Re: Solr Replication
Posted by Shawn Heisey <el...@elyograg.org>.
On 2/28/2023 2:20 AM, Paul Ryder wrote:
> All,
>
> I see warnings in the Solr master replication like this
>
> 2023-02-24 18:10:40.964 WARN (qtp156856360-13173) [ x:Fred_apis_responses_index] o.a.s.h.ReplicationHandler Exception while writing response for params: generation=394103&qt=/replication&file=segments_8g3b&checksum=true&compression=true&wt=filestream&command=filecontent => java.nio.file.NoSuchFileException: E:\Solr8.1.1\Fred_apis_responses_index\data\restore.20221207055103765\segments_8g3b
> at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
Not sure why a file that is expected to be there isn't there.
> And warnings/errors on Slave servers such as
>
> File _exa0_Lucene50_0.tim did not match. expected checksum is 1661977412 and actual is checksum 116298600. expected length is 4648 and actual length is 4145
This sounds like a file got corrupted. Something changed it.
> Error removing directory E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425 before core close:java.io.IOException: Unable to delete file: E:\Solr8.1.1\Fred_documentsearch_index\data\index.20230228073716425\_ex9o.cfs
>
> Solr 8.1.1 on Java 8 - Windows
Windows can't delete a file that something has open in ANY mode. Linux
and other similar operating systems have no trouble deleting open
files. Software like Solr just works better on most open source
operating systems than on Windows.
The question comes down to why that file is open when Lucene (the
central Search API used by Solr) tries to delete it. This can be caused
by antivirus software, backup software, or several other possibilities.
I can see antivirus software causing all of the problems you have
described. You should exclude the place Solr stores its indexes from
scanning by antivirus software.
In addition to problems that running on Windows can cause, there is the
fact that Solr 8.1.1 is nearly four years old and is basically
unsupported. Any problems you find would need to be demonstrated as
happening in the latest Solr version, and due to a bug in Solr, not some
aspect of the environment.
Thanks,
Shawn