[
https://issues.apache.org/jira/browse/OAK-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3148:
-------------------------------
Fix Version/s: 1.4
> Online migration process for the binaries
> -----------------------------------------
>
> Key: OAK-3148
> URL: https://issues.apache.org/jira/browse/OAK-3148
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, upgrade
> Reporter: Tomek Rękawek
> Priority: Minor
> Fix For: 1.4
>
>
> For clients that want to migrate their blob stores, let's add a new feature
> that allows copy them in the background.
> AC:
> # SplitBlobStore
> ## Administrator can configure Oak to use the {{SplitBlobStore}} that
> references the source (old) and the destination (new) blob store.
> ## Data stores can be used as well via the {{DataStoreBlobStore}}.
> ## On the read operation, if the requested blob exists on the new store,
> SplitBlobStore will return it.
> ## Otherwise, SplitBlobStore will try to read the blob from the old store.
> ## All write requests will be directed to the new blob store.
> # Copy process
> ## Administrator can start, stop and resume the copy process using JMX
> command.
> ## Administrator can see the progress in JMX and logs
> ## The process will read the {{SplitBlobStore}} configuration and copy the
> binaries from source to destination
> ## Once a binary is moved, its reference in the {{NodeStore}} is updated and
> commited.
> ## Only the head revision has to be updated.
> The idea is that after all binaries are copied, the old revisions will be
> gradually removed by the compaction mechanisms and then binaries will be
> removed from the source store by the blob garbage collector. Future
> improvements are possible, eg. to invoke the compaction and GC manually.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
