[
https://issues.apache.org/jira/browse/OAK-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900199#comment-13900199
]
Alex Parvulescu commented on OAK-1161:
--------------------------------------
continuing on with the http based failover. I played with the _HttpStore_ a bit
and I have some questions:
- first off authentication, how will it handle issuing GET requests without a
notion of user/pass. I hacked in a simple workaround using admin/admin, but I'm
not sure this will the the final solution [0]
- second, there is no servlet (yet) exposing the paths on the other side.
'/j/' '/s/' don't exist, I'm assuming this is left as a TODO?
The solution looks straightforward, wrap the NodeStore in a servlet and expose
the _getJournal_, _readSegment_ and _writeSegment_ operations.
Am I on the right track here?
[0]
{code}
String authString = user + ":" + password;
byte[] authEncBytes = Base64.encodeBase64(authString.getBytes());
String authStringEnc = new String(authEncBytes);
final URL url = new URL(base, fragment);
final URLConnection urlConnection = url.openConnection();
urlConnection.setRequestProperty("Authorization", "Basic "
+ authStringEnc);
{code}
> Simple failover for TarMK-based installations
> ---------------------------------------------
>
> Key: OAK-1161
> URL: https://issues.apache.org/jira/browse/OAK-1161
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: segmentmk
> Reporter: Michael Marth
> Assignee: Alex Parvulescu
> Fix For: 0.17
>
>
> At the moment we have a Mongo-based MK impl that Oak users for scalable
> deployments and TarMK for standalone (performant) deployments. I think it is
> OK to not implement some sort of "scalability" into TarMK, even if I realize
> that the hierarchical journals allow us to do that later if we want to.
> However, it would even now be great to have a failover option for TarMK
> (MongoMK implictly offers this through replicas). This would not be about
> clustering or scalability, but only about reliability.
> I think there are 2 parts to this:
> # keeping a standby repository (slave) in sync and
> # the actual fail over.
> For the first part there could be a relatively simple way to implement this:
> Let's consider that there is only one slave and that the slave does not
> accept writes. Given the MVCC nature of the tar files we could simply sync
> the (append-only) tar files from the master to the slave on an ongoing basis.
> This could be similar to an rsync (or even use actual rsync)
> The slave would keep on receiving and locally persisting these files.
> Also, the slave would either need to be in a state where it is blocks writes
> or even in some sort of sleep state.
> I think this synchronization of files could be done a rather robust way where
> shaky networks or high latency could be recovered from by choosing a proper
> way of transfer.
> This sync to a remote system could be implemented similarly than a
> tarMK-based incremental backup (OAK-1159).
> For the failover:
> Ideally, we would have 2 implementations: a native failover and an external
> switch (like MBean or via HTTP) that would make the slave stop accepting
> files from master and start up on the last completely received revision. But
> simply having the second option would be a good start.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
