[Koha-devel] [Koha] Redundant infrastructure for Koha

[Michael Hafen]

Tahoe-lafs looks interesting if one where locked to cloud storage.  I'm
planning to deal with storage on the local level, where a simple
copy-on-write style system is sufficient.  I don't anticipate needing the
kind of security provided by Tahoe-lafs, so it seems like overkill to me.

As for HA-Proxy, that might be good for client requests to Zebra.  The real
problem is handling writes to Zebra.  Using the queue table in the database
would keep one copy up to date, but short of a copy-on-write system I have
my doubts about being able to cluster Zebra.  Even with a shared file
system I expect Zebra tries to lock it's files, which would mean more than
one Zebra server on the same directory of the same file system probably
wouldn't work.  ( I ran into that with Mysql in an earlier attempt at
redundancy, and it corrupted many tables when both servers were access the
same files at the same time. )


On Tue, Nov 8, 2016 at 2:11 AM, SUZUKI Arthur <arthur.suzuki at univ-lyon3.fr>
wrote:

> Hi,
>
> For Zebra and Web-server, this could be a good use case for HA-Proxy.
>
> Never used this myself but I have read some documentations about how it
> can be used to setup redundancy and/or load-balancing between servers for
> applications that doesn't support this feature out-of the box.
>
> For file storage distributed across multiple nodes there is this newcomer
> called Tahoe-LAFS :
>
> https://tahoe-lafs.org/trac/tahoe-lafs
>
> Hope this help your purpose.
>
> I have to say I've some interests into the question myself, don't hesitate
> to share your results!
>
> Regards,
>
> Arthur
>
>
> Le 07/11/2016 à 22:42, Galen Charlton a écrit :
>
>> Hi,
>>
>> On Mon, Nov 7, 2016 at 4:36 PM, Michael Hafen <michael.hafen at washk12.org>
>> wrote:
>>
>>> Has anyone tried access Zebra through a network socket instead of the
>>> unix
>>> one?  I was under the impression that that was possible.
>>>
>> It is, and it's as easy as changing the following lines in koha-conf.xml
>> from:
>>
>> <listen id="biblioserver" >unix:/var/run/koha/SITE/bibliosocket</listen>
>> <listen id="authorityserver" >unix:/var/run/koha/SITE/autho
>> ritysocket</listen>
>>
>> to
>>
>> <listen id="biblioserver" >tcp:HOST_OR_IP:PORT</listen>
>> <listen id="authorityserver" >tcp:HOST_OR_IP:ANOTHER_PORT</listen>
>>
>> Of course, depending on how you arrange things, local tweaks to the
>> indexer jobs would be required to ensure that all of the copies of the
>> Zebra databases got updated.
>>
>> Regards,
>>
>> Galen
>>
>
> --
> Arthur SUZUKI
> Service informatique des bibliothèques
> BIBLIOTHÈQUES UNIVERSITAIRES
> Université Jean Moulin Lyon 3
> 6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08
> ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr
> L'Université Jean Moulin est membre fondateur de l'Université de Lyon
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20161108/00b69c54/attachment.html>