search

Islandora-Collaboration-Group / ISLE

Islandora Enterprise (ISLE) is a community project that addresses two of the most significant pain-points in Islandora: installation and maintenance.
https://Islandora-Collaboration-Group.github.io/ISLE/
GNU General Public License v3.0
32 stars 34 forks source link

Document how to mount solr data on ext drive #246

Open bseeger opened 5 years ago

bseeger commented 5 years ago

I have a use case where I'd like to mount solr data on an external drive. Essentially my rootfs is small and I want to make sure that the solr docker volume doesn't fill it up.

If I, on a fresh install, create a bind mount via the docker-compose file in ISLE, I run into a snag where the solr docker container already has the solr collection info in /usr/local/solr, so if I tell it to bind mount that directory, my external mount point essentially squashes what's there in the container already. This renders solr unusable because it's collection info is no longer accessible. (removing the bind mount makes it work again).

The proper way to do what I want to do, with the system they way it is, is to (for solr):

I think we should document this - but I'm not sure how rare this use case will be. I like to partition off things that might grow, so I'd probably want to do this anyways even if I didn't have small rootfs disk space.

SummittDweller commented 5 years ago

I’m guessing it’s not that rare… I had the same issue, and resolved it in the same manner, a few months ago.

On Apr 17, 2019, at 8:48 AM, B. Seeger notifications@github.com<mailto:notifications@github.com> wrote:

I have a use case where I'd like to mount solr data on an external drive. Essentially my rootfs is small and I want to make sure that the solr docker volume doesn't fill it up.

If I, on a fresh install, create a bind mount via the docker-compose file in ISLE, I run into a snag where the solr docker container already has the solr collection info in /usr/local/solr, so if I tell it to bind mount that directory, my external mount point essentially squashes what's there in the container already. This renders solr unusable because it's collection info is no longer accessible. (removing the bind mount makes it work again).

The proper way to do what I want to do, with the system they way it is, is to (for solr):

I think we should document this - but I'm not sure how rare this use case will be. I like to partition off things that might grow, so I'd probably want to do this anyways even if I didn't have small rootfs disk space.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Islandora-Collaboration-Group/ISLE-Documentation/issues/139, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAHKYC2DPT3N24CNMHUPWALPQ4TBTANCNFSM4HGUNBRA.

g7morris commented 5 years ago

I agree this should be documented and data storage is a challenge with ISLE and Docker itself for sure.

I think I've also found another method as what you're both proposing in my opinion is simply to reconstruct the Solr build process?

Absolutely what you discuss re starting up and copying out Solr data is a legit method but one can also accomplish this process by:

I would be curious to see if this works as another utility-script candidate?

g7morris commented 4 years ago

@bseeger Sorry for late reply here. What is the path for your bind-mount for Solr? Have you considered testing bind-mounting this path /usr/local/solr/collection1/data:/<path to the bindmounted>/solr/ I think that would allow things to work