Docker has a "layered" filesystem strategy, where new writes are written to a top layer, so maybe there's a way to do this with docker. Pretty speculative, but:
- Start a docker container based on an image containing Solr, but no index data. - Build your index within the image. - Shutdown solr and build a new Docker image from the container. - Now start two new docker containers from that image, both running Solr. Getting to this architecture may have some gotchas, as you clearly don't want to reindex 350gb+400gb, and don't have the storage to copy it over into a docker image. Maybe OS-level backup/restore could solve this problem. Also, getting docker to store/load images from NFS is a small detail - they either have configuration or you can use mount/symbolic links. Pardon the outlandish solution, but I tend to think Systems engineering fix first, and Java coding second. I think that maybe they could help on the Java side over at lucene-user, because a Java solution would need to be pretty deep, and involving changing some of the basics on how (whether) locking is done. -----Original Message----- From: David Hastings [mailto:hastings.recurs...@gmail.com] Sent: Friday, May 19, 2017 1:33 PM To: solr-user@lucene.apache.org Subject: Re: Solr in NAS or Network Shared Drive The reason for me to want to try it is because replication is not possible on the single machine, as the index size is around 350gb+another 400gb, and i dont have enough SSD to cover a replication from the master node. Also i have a theory and heard this as well from a presentation at the LR conference in Boston this past year, that multiple solr instances on one machine performs better than multiple machines, would be interesting to have solr have a "read only"/"listen" state to do no writing to the index, but keep referencing the index properties/version files. On Fri, May 19, 2017 at 1:26 PM, Davis, Daniel (NIH/NLM) [C] < daniel.da...@nih.gov> wrote: > Better off to just do Replication to the slave using the replication > handler. > > However, if there is no network connectivity, e.g. this is an offsite > cold/warm spare, then here is a solution: > > The NAS likely supports some Copy-on-write/snapshotting capabilities. If > your systems people will work with you, you can use the > replication/backup handler to take a NAS snapshot just after hard commit, and > then have the > snapshot replicated to another volume. I suspect Solr will have to be > started on the cold/warm spare when you do a failover to offsite, > because I know of no way to have the OS react to events when a > snapshot is replicated by the NAS. > > This kind of solution is what you might see for an Oracle, or any > other binary ACID database, so you can look at best practices for > integrating these products with Netapp or EMC Celera for more ideas. > > -----Original Message----- > From: Rick Leir [mailto:rl...@leirtech.com] > Sent: Friday, May 19, 2017 12:40 PM > To: solr-user@lucene.apache.org > Subject: Re: Solr in NAS or Network Shared Drive > > For an experiment, mount the NAS filesystem ro (readonly). Is there > any way to tell Solr not to bother with a lockfile? And what happens > if an update or add gets requested by mistake, does it take down Solr? > > Why not do this all the simple way, and just replicate? > > On May 19, 2017 10:41:19 AM EDT, David Hastings < > hastings.recurs...@gmail.com> wrote: > >ive always wanted to experiment with this, but you have to be very > >careful that only one of the cores, or neither, can do ANY writes, > >also if you have a suggester index you need to make sure that each > >core builds their own independently. In any case from every thing > >ive read the general answer is dont do it. would like to hear other > >peoples thoughts on this however. > > > >On Fri, May 19, 2017 at 10:33 AM, Ravi Kumar Taminidi < > >ravi.tamin...@whitepine-st.com> wrote: > > > >> Hello, Scenario: Currently we have 2 Solr Servers running in 2 > >different > >> servers (linux), Is there any way can we make the Core to be > >> located > >in NAS > >> or Network shared Drive so both the solrs using the same Index. > >> > >> Let me know if any performance issues, our size of Index is appx 1GB. > >> > >> Thanks > >> > >> Ravi > >> > >> -----Original Message----- > >> From: biplobbiswas [mailto:revolutionisme+s...@gmail.com] > >> Sent: Friday, May 19, 2017 9:23 AM > >> To: solr-user@lucene.apache.org > >> Subject: Re: Nested Document is flattened even with @Field(child = > >true) > >> annotation > >> > >> Hi > >> Mikhail Khludnev-2 wrote > >> > Hello, > >> > > >> > You need to use > >> > > >https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherP > >a > >> > rsers-BlockJoinQueryParsers > >> > and > >> > > >https://cwiki.apache.org/confluence/display/solr/Transforming+Result+ > >D > >> > > >ocuments#TransformingResultDocuments-[child]-ChildDocTransformerFacto > >r > >> > y > >> > to get the nested data back. > >> > > >> > > >> > -- > >> > Sincerely yours > >> > Mikhail Khludnev > >> > >> I had already gone through those links you posted and they talk > >> about retrieving after indexing. My problem is that my documents > >> are not > >indexed > >> in a nested structure. > >> > >> Can you please look at the first comment as well where I posted a > >sample > >> code and sample response which i get back. > >> > >> Because its creating distinct documents for nested structure > >> > >> > >> > >> > >> -- > >> View this message in context: http://lucene.472066.n3. > >> nabble.com/Nested-Document-is-flattened-even-with-Field- > >> child-true-annotation-tp4335877p4335891.html > >> Sent from the Solr - User mailing list archive at Nabble.com. > >> > > -- > Sorry for being brief. Alternate email is rickleir at yahoo dot com >
