Re: [jgit-dev] Ketch: multi-master replicated Git

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, Jan 13, 2016 at 8:30 AM, Saša Živkov <zivkov@xxxxxxxxx> wrote:
> On Wed, Jan 13, 2016 at 4:07 PM, Luca Milanesio <luca.milanesio@xxxxxxxxx>
> wrote:
>>
>> Hi Shawn,
>> worth sharing on the repo-discuss mailing list as well :-)
>>
>> Could then I use Git Ketch to manage the agreement process on pushes (as
>> Cassandra gives me some headache with that) and still use another DFS
>> implementation based on Git objects on Cassandra?
>
>
> If I understood the announcement [1] correctly you can.

Yes, this should be supported.

It gets a bit confusing because I think you are talking about having
like 1 object store in a Cassandra cluster, and then the reference
data is managed by Ketch? Ketch stores the references in the object
store using RefTree, but still needs to use an odd number of copies of
refs/txn/accepted on durable storage to form the voting system.

To be honest I didn't consider a system layout such as this before. Up
until this email I was thinking a minimum Ketch 3.0 (3 voters, 0
followers) system would be 3 separate installations, e.g. 3 Linux
servers running Git on local disk. With Cassandra its more like 3
isolated Cassandra clusters providing 3 copies of the repositories,
and if each Cassandra cluster itself is probably 3 machines at
minimum, this is like a 9 machine system.

If those 9 machines are in the same data center than you may be better
off with something like HDFS providing disk storage for JGit DFS and
using 3 local disks or 3 small installations of reliable databases for
the RefTree bootstrap layer (where Ketch stores its
refs/txn/accepted).