Thanks Alexander, what a valuable ressource :).
- Em
--
View this message in context:
http://lucene.472066.n3.nabble.com/Multicore-Relaod-Theoretical-Question-tp2293999p2321335.html
Sent from the Solr - User mailing list archive at Nabble.com.
Em,
that's correct. You can use 'lsof' to see file handles still in use.
See
http://0xfe.blogspot.com/2006/03/troubleshooting-unix-systems-with-lsof.html,
"Recipe #11".
-Alexander
On Sun, Jan 23, 2011 at 1:52 AM, Em wrote:
>
> Hi Alexander,
>
> thank you for your response.
>
> You said that th
Hi Alexander,
thank you for your response.
You said that the old index files were still in use. That means Linux does
not *really* delete them until Solr frees its locks from it, which happens
while reloading?
Thank you for sharing your experiences!
Kind regards,
Em
Alexander Kanarsky wr
Em,
yes, you can replace the index (get the new one into a separate folder
like index.new and then rename it to the index folder) outside the
Solr, then just do the http call to reload the core.
Note that the old index files may still be in use (continue to serve
the queries while reloading), eve
Hi Erick,
thanks for your response.
Yes, it's really not that easy.
However, the target is to avoid any kind of master-slave-setup.
The most recent idea i got is to create a new core with a data-dir pointing
to an already existing directory with a fully optimized index.
Regards,
Em
--
View t
This seems far too complex to me. Why not just optimize on the master
and let replication do all the rest for you?
Best
Erick
On Fri, Jan 21, 2011 at 1:07 PM, Em wrote:
>
> Hi,
>
> are there no experiences or thoughts?
> How would you solve this at Lucene-Level?
>
> Regards
>
>
> Em wrote:
> >
Hi,
are there no experiences or thoughts?
How would you solve this at Lucene-Level?
Regards
Em wrote:
>
> Hello list,
>
> I got a theoretical question about a Multicore-Situation:
>
> I got two cores: active, inactive
>
> The active core serves all the queries.
>
> The inactive core is th
