[
https://issues.apache.org/jira/browse/OAK-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3148:
-------------------------------
Description:
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.
was:
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}}.
## If the requested blob exists on the destination 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.
> 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
>
> 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)
