You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by mr...@apache.org on 2018/07/09 08:53:19 UTC
svn commit: r1835390 [4/23] - in /jackrabbit/site/live/oak/docs: ./
architecture/ coldstandby/ features/ nodestore/ nodestore/document/
nodestore/segment/ oak-mongo-js/ oak_api/ plugins/ query/ security/
security/accesscontrol/ security/authentication/...
Modified: jackrabbit/site/live/oak/docs/nodestore/document/mongo-document-store.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/document/mongo-document-store.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/document/mongo-document-store.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/document/mongo-document-store.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – MongoDB DocumentStore</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -241,60 +241,37 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
- --><h1>MongoDB DocumentStore</h1>
+ -->
+<h1>MongoDB DocumentStore</h1>
<p>The <tt>MongoDocumentStore</tt> is one of the backend implementations for the <a href="../documentmk.html">DocumentNodeStore</a>. The MongoDocumentStore use MongoDB to persist nodes as documents.</p>
<div class="section">
<h2><a name="Recommendations"></a><a name="recommendations"></a> Recommendations</h2>
<p>Before deploying a MongoDocumentStore on MongoDB, make sure recommendations described in <a class="externalLink" href="https://docs.mongodb.com/manual/administration/production-notes/">production notes</a> have been applied.</p>
<p>The recommended MongoDB version depends on the Oak release. Below table lists the recommended MongoDB version for each Oak release. More recent MongoDB versions may also work, but are untested.</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
<th>Oak Release </th>
-
-<th>MongoDB version</th>
- </tr>
- </thead>
- <tbody>
-
+<th> MongoDB version</th></tr>
+</thead><tbody>
+
<tr class="b">
-
<td>1.0.x </td>
-
-<td>2.6.x</td>
- </tr>
-
+<td> 2.6.x</td></tr>
<tr class="a">
-
<td>1.2.x </td>
-
-<td>3.2.x</td>
- </tr>
-
+<td> 3.2.x</td></tr>
<tr class="b">
-
<td>1.4.x </td>
-
-<td>3.2.x</td>
- </tr>
-
+<td> 3.2.x</td></tr>
<tr class="a">
-
<td>1.6.x </td>
-
-<td>3.2.x</td>
- </tr>
-
+<td> 3.2.x</td></tr>
<tr class="b">
-
<td>1.8.x </td>
-
-<td>3.4.x</td>
- </tr>
- </tbody>
+<td> 3.4.x</td></tr>
+</tbody>
</table>
<p>For production deployments use a replica-set with at least three mongod instances and a majority write concern. Fewer than three instances (e.g. two instances and an arbiter) may lead to data loss when the primary fails.</p>
<p>When using MongoDB 3.4 or newer, set the <a class="externalLink" href="https://docs.mongodb.com/manual/core/read-preference/#maxstalenessseconds">maxStalenessSeconds</a> option in the MongoDB URI to <tt>90</tt>. This is an additional safeguard and will prevent reads from a secondary that is too far behind.</p>
@@ -304,8 +281,9 @@
<p>The recommended method to initialize a <tt>DocumentNodeStore</tt> with a <tt>MongoDocumentStore</tt> is using an OSGi container and configure the <tt>DocumentNodeStoreService</tt>. See corresponding <a href="../../osgi_config.html">Repository OSGi Configuration</a>.</p>
<p>Alternatively a MongoDB based DocumentNodeStore can be created with the help of a <tt>MongoDocumentNodeStoreBuilder</tt>.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">DocumentNodeStore store = newMongoDocumentNodeStoreBuilder()
+<div>
+<div>
+<pre class="source">DocumentNodeStore store = newMongoDocumentNodeStoreBuilder()
.setMongoDB("mongodb://localhost:27017", "oak", 0).build();
// do something with the store
NodeState root = store.getRoot();
@@ -313,17 +291,20 @@ NodeState root = store.getRoot();
// dispose it when done
store.dispose();
</pre></div></div>
+
<p>Please note, even though the default is to store blobs in MongoDB, this is not a recommended setup. See also <a href="#recommendations">recommendations</a>.</p></div>
<div class="section">
<h2><a name="Read_preference"></a><a name="read-preference"></a> Read preference</h2>
<p>Without any read preference specified in the MongoDB URI, most read operations will be directed to the MongoDB primary to ensure consistent reads. Functionality like Revision Garbage Collection does not have such a strict requirement and will therefore scan (read) for garbage with a read preference of <tt>secondaryPreferred</tt>. This takes pressure off the primary.</p>
-<p>When the <tt>MongoDocumentStore</tt> is configured with an explicit read preference via the MongoDB URI, the read preference is considered a hit. The implementation may still read from the primary when it cannot guarantee a consistent read from a secondary. This may be the case when a secondary lags behind and a read happens for a document that was recently modified.</p>
+<p>When the <tt>MongoDocumentStore</tt> is configured with an explicit read preference via the MongoDB URI, the read preference is considered a hint. The implementation may still read from the primary when it cannot guarantee a consistent read from a secondary. This may be the case when a secondary lags behind and a read happens for a document that was recently modified.</p>
<p>A common use case is setting a read preference for a nearby secondary. This can be achieved with <tt>readPreferenceTags</tt> in the MongoDB URI.</p>
<p>The below example will prefer a secondary with tag <i>dc:ny,rack:1</i>. If no such secondary is available, the read operation will target to a secondary with tag <i>dc:ny</i> and if no such secondary is available either, any available secondary is chosen. As a final fallback the read will be served from the primary.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">mongodb://example1.com,example2.com,example3.com/?readPreference=secondaryPreferred&readPreferenceTags=dc:ny,rack:1&readPreferenceTags=dc:ny&readPreferenceTags=
+<div>
+<div>
+<pre class="source">mongodb://example1.com,example2.com,example3.com/?readPreference=secondaryPreferred&readPreferenceTags=dc:ny,rack:1&readPreferenceTags=dc:ny&readPreferenceTags=
</pre></div></div>
+
<p>Refer to <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/#read-preference-options">Read Preference Options</a> and <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/#write-concern-options">Write Concern Options</a> for more details.</p>
<p>Starting with Oak 1.9.3 the <tt>MongoDocumentStore</tt> automatically uses client sessions with causal consistency when running on MongoDB 3.6 or newer. This feature can be disabled by setting a system property: <tt>-Doak.mongo.clientSession=false</tt>.</p>
<p>Causal consistent client sessions allows <tt>MongoDocumentStore</tt> to always read from a secondary when configured with the relevant read preference and at the same time guarantee the required consistency. This is most useful in a distributed deployment with multiple Oak processes connected to a MongoDB replica-set. Putting a MongoDB secondary close to an Oak process ensures low read latency when Oak is configured to always read from the nearby MongoDB secondary.</p>
@@ -336,8 +317,9 @@ store.dispose();
<p>In addition to specifying the <a class="externalLink" href="http://docs.mongodb.org/manual/core/read-preference/">read preference</a> and <a class="externalLink" href="http://docs.mongodb.org/manual/core/write-concern/">write concern</a> in the MongoDB URI, those two parameters can also be set and changed at runtime by setting the property <tt>readWriteMode</tt> in the cluster node metadata. A cluster node will pick up the change within ten seconds (when it renews the lease of the cluster node id). This is a string property with the format <tt>'readPreference=<preference>&w=<writeConcern>'</tt> similar to the way it is used in MongoDB URI. Just that it does not include other option details.</p>
<p>The following MongoDB shell command will set the read preference to <tt>primary</tt> and the write concern to <tt>majority</tt> for all cluster nodes:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">> db.clusterNodes.update({},
+<div>
+<div>
+<pre class="source">> db.clusterNodes.update({},
{$set: {readWriteMode:'readPreference=primary&w=majority'}},
{multi: true})
</pre></div></div></div>
Modified: jackrabbit/site/live/oak/docs/nodestore/document/node-bundling.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/document/node-bundling.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/document/node-bundling.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/document/node-bundling.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Bundling Nodes</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -241,114 +241,112 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
- --><h1>Bundling Nodes</h1>
-
+ -->
+<h1>Bundling Nodes</h1>
<ul>
-
+
<li><a href="#bundling-nodes">Bundling Nodes</a>
-
<ul>
-
+
<li><a href="#bundling-usage">Usage</a>
-
<ul>
-
+
<li><a href="#bundling-pattern">Bundling Pattern</a></li>
- </ul></li>
-
-<li><a href="#bundling-example">Bundling Examples </a>
-
-<ul>
-
-<li><a href="#bundling-usage-file">Bundling nt:file </a></li>
-
+</ul>
+</li>
+<li><a href="#bundling-example">Bundling Examples </a>
+<ul>
+
+<li><a href="#bundling-usage-file">Bundling nt:file </a></li>
<li><a href="#bundling-usage-file">Bundling app:Asset</a></li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="#bundling-design-considerations">Design Considerations</a></li>
-
<li><a href="#bundling-benefits-limits">Benefits and Limitations</a>
-
<ul>
-
+
<li><a href="#bundling-benefits">Benefits</a></li>
-
<li><a href="#bundling-limits">Limitations</a></li>
- </ul></li>
- </ul></li>
+</ul>
+</li>
+</ul>
+</li>
</ul>
<p><tt>@since Oak 1.6</tt></p>
<p>Document NodeStore stores the JCR nodes as Document in underlying <tt>DocumentStore</tt>. So depending on backend that Document is stored in following way</p>
-
<ul>
-
+
<li>MongoDB - 1 JCR node is mapped to 1 MongoDB Document in <tt>nodes</tt> collection</li>
-
<li>RDB - 1 JCR node is mapped to 1 row in <tt>nodes</tt> table</li>
</ul>
-<p>The remaining part of the document will focus on the <tt>MongoDocumentStore</tt> to explain and illustrate bundling concepts. </p>
+<p>The remaining part of the document will focus on the <tt>MongoDocumentStore</tt> to explain and illustrate bundling concepts.</p>
<p>For very fine grained content with many nodes and only few properties per node it is more efficient to bundle multiple nodes into a single MongoDB document. Such bundling mostly benefits reading because there are less round-trips to the backend. At the same time storage footprint is lower because metadata overhead is per document. This is specially important for the various indexes like <tt>_id</tt> and <tt>_modified_1__id_1</tt> as they have less entries indexed.</p>
<div class="section">
<h2><a name="Usage"></a><a name="bundling-usage"></a> Usage</h2>
<p>Bundling is enabled on per nodetype basis. Bundling definitions are defined as content in the repository under <tt>/jcr:system/rep:documentStore/bundlor</tt>.</p>
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">+ <node type name>
- - pattern - multi
-</pre></div></div>
+<li>< node type name >
+<ul>
+
+<li>pattern - multi</li>
+</ul>
+</li>
+</ul>
<p>For example below content structure enables bundling for nodes of type <tt>nt:file</tt> and <tt>app:Asset</tt></p>
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">+ jcr:system
- + documentstore
- + bundlor
- + nt:file (oak:Unstructured)
- - pattern = ["jcr:content"]
- + app:Asset
- - pattern = ["jcr:content/metadata", "jcr:content/renditions", "jcr:content"]
-</pre></div></div>
-<p>Once this is done any node of type <tt>nt:file</tt> created <i>after</i> this will be stored in bundled format. Nodes created <i>before</i> the configuration was added are not affected and their underlying documents are not rewritten.</p>
+<li>jcr:system
+<ul>
+<li>documentstore
<ul>
-
+
+<li>bundlor</li>
+<li>nt:file (oak:Unstructured)
+<ul>
+
+<li>pattern = [“jcr:content”]</li>
+</ul>
+</li>
+<li>app:Asset
+<ul>
+
+<li>pattern = [“jcr:content/metadata”, “jcr:content/renditions”, “jcr:content”]</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+<p>Once this is done any node of type <tt>nt:file</tt> created <i>after</i> this will be stored in bundled format. Nodes created <i>before</i> the configuration was added are not affected and their underlying documents are not rewritten.</p>
+<ul>
+
<li><i>Bundling Roots</i> - Nodes having type for which bundling patterns are defined</li>
-
<li><i>Bundling Pattern</i> - Pattern defined under bundling config path which governs which all relative nodes are bundled</li>
-
-<li><i>Micro Tree</i> - Refers to content structure which is bundled. Such content structures are <i>micro</i> tree and multiple such micro tree form the whole repository tree</li>
-
+<li><i>Micro Tree</i> - Refers to content structure which is bundled. Such content structures are <i>micro</i> tree and multiple such micro tree form the whole repository tree</li>
<li><i>Bundling ratio</i> - Ratio of number of JCR nodes bundled as part of bundling root node. For example for nt:file its 2</li>
</ul>
<p>Key points to note here</p>
-
<ol style="list-style-type: decimal">
-
+
<li>Bundling patterns can be defined for either jcr:mixinTypes or jcr:primaryType.</li>
-
<li>Bundling pattern defined for mixins take precedence over those defined for primary node type.</li>
-
<li>Bundling only impacts content created after the bundling pattern is set.</li>
-
<li>Existing content is not modified.</li>
-
<li>This feature can be enabled or disabled anytime.</li>
-
-<li>If bundling is disable later then it only prevents bundling of nodes created after disabling. Existing bundled nodes remain bundled.</li>
-
-<li>Bundling pattern is baked in into the created node. So if bundling pattern is changed later, it only affects new bundled roots created after the change.</li>
-
-<li>Writes to <tt>/jcr:system/rep:documentStore/bundlor</tt> should be restricted to system admin as this is an important configuration and any mis configuration here can have severe adverse impact on repository.</li>
-
-<li>While selecting bundling rule for any node node type inheritance is <i>not</i> considered. Bundling pattern is selected based on exact match of jcr:mixinTypes or jcr:primaryType names.</li>
+<li>If bundling is disable later then it only prevents bundling of nodes created after disabling. Existing bundled nodes remain bundled.</li>
+<li>Bundling pattern is baked in into the created node. So if bundling pattern is changed later, it only affects new bundled roots created after the change.</li>
+<li>Writes to <tt>/jcr:system/rep:documentStore/bundlor</tt> should be restricted to system admin as this is an important configuration and any mis configuration here can have severe adverse impact on repository.</li>
+<li>While selecting bundling rule for any node node type inheritance is <i>not</i> considered. Bundling pattern is selected based on exact match of jcr:mixinTypes or jcr:primaryType names.</li>
</ol>
<div class="section">
<h3><a name="Bundling_Pattern"></a><a name="bundling-pattern"></a> Bundling Pattern</h3>
<p>Bundling pattern is a multi value value property. The pattern elements are list of relative node paths which should be bundled as part of <i>bundling root</i>. The relative node paths can be of following type:</p>
-
<ul>
-
+
<li>Static - Like ‘jcr:content’, ‘jcr:content/metadata’.</li>
-
<li>Wildcard <i>(Experimental Feature)</i> - Like ‘jcr:content/renditions/**’. This would bundle all nodes under relative paths ‘jcr:content/renditions’</li>
</ul>
<p><b>Support for wildcard patterns is currently experimental</b></p></div></div>
@@ -357,62 +355,85 @@
<div class="section">
<h3><a name="Bundling_nt:file"></a><a name="bundling-usage-file"></a> Bundling nt:file</h3>
<p>Lets take an example of <tt>nt:file</tt> node like below</p>
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">+ /content/book.jpg
- - jcr:createdBy = "admin"
- - jcr:primaryType = "nt:file"
- + jcr:content
- - jcr:data = <blob id>
- - jcr:mimeType = "text/plain"
- - jcr:uuid = "56befaee-f5fe-4252-87f8-0dcc8a624dd5"
- - jcr:lastModifiedBy = "admin"
- - jcr:primaryType = "nt:resource"
-</pre></div></div>
+<li>/content/book.jpg
+<ul>
+
+<li>jcr:createdBy = “admin”</li>
+<li>jcr:primaryType = “nt:file”</li>
+<li>jcr:content
+<ul>
+
+<li>jcr:data = < blob id ></li>
+<li>jcr:mimeType = “text/plain”</li>
+<li>jcr:uuid = “56befaee-f5fe-4252-87f8-0dcc8a624dd5”</li>
+<li>jcr:lastModifiedBy = “admin”</li>
+<li>jcr:primaryType = “nt:resource”</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
<p><img src="node-bundling-file.png" alt="Bundling Nodes" /></p>
<p>This JCR node structure would be stored in MongoDB in 2 documents</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">{
+<div>
+<div>
+<pre class="source">{
"_id" : "2:/content/book.jpg",
- "jcr:created" : {"r151ce899ac3-0-1" : "\"dat:2015-12-23T16:41:43.055+05:30\""},
- "_modified" : NumberLong(1450869100),
- "_deleted" : { "r151ce899ac3-0-1" : "false"},
- "jcr:createdBy" : { "r151ce899ac3-0-1" : "\"admin\""},
- "_commitRoot" : { "r151ce899ac3-0-1" : "0"},
- "_children" : true,
+ "jcr:created" : {"r151ce899ac3-0-1" : "\"dat:2015-12-23T16:41:43.055+05:30\""},
+ "_modified" : NumberLong(1450869100),
+ "_deleted" : { "r151ce899ac3-0-1" : "false"},
+ "jcr:createdBy" : { "r151ce899ac3-0-1" : "\"admin\""},
+ "_commitRoot" : { "r151ce899ac3-0-1" : "0"},
+ "_children" : true,
"jcr:primaryType": { "r151ce899ac3-0-1" : "\"nam:nt:file\""},
- "_modCount" : NumberLong(1)
+ "_modCount" : NumberLong(1)
},
{
"_id" : "3:/content/book.jpg/jcr:content",
"_bin" : NumberLong(1),
"_modified" : NumberLong(1450869100),
"jcr:lastModified" : { "r151ce899ac3-0-1" : "\"dat:2015-12-23T16:41:43.056+05:30\""},
- "_deleted" : { "r151ce899ac3-0-1" : "false" },
- "jcr:data" : { "r151ce899ac3-0-1" : "\":blobId:xxx\""},
- "_commitRoot" : { "r151ce899ac3-0-1" : "0" },
- "jcr:mimeType" : { "r151ce899ac3-0-1" : "\"text/plain\""},
- "jcr:uuid" : { "r151ce899ac3-0-1" : "\"56befaee-f5fe-4252-87f8-0dcc8a624dd5\""},
+ "_deleted" : { "r151ce899ac3-0-1" : "false" },
+ "jcr:data" : { "r151ce899ac3-0-1" : "\":blobId:xxx\""},
+ "_commitRoot" : { "r151ce899ac3-0-1" : "0" },
+ "jcr:mimeType" : { "r151ce899ac3-0-1" : "\"text/plain\""},
+ "jcr:uuid" : { "r151ce899ac3-0-1" : "\"56befaee-f5fe-4252-87f8-0dcc8a624dd5\""},
"jcr:lastModifiedBy": { "r151ce899ac3-0-1" : "\"admin\""},
- "jcr:primaryType" : { "r151ce899ac3-0-1" : "\"nam:nt:resource\""},
- "_modCount" : NumberLong(1)
+ "jcr:primaryType" : { "r151ce899ac3-0-1" : "\"nam:nt:resource\""},
+ "_modCount" : NumberLong(1)
}
</pre></div></div>
+
<p>Now with bundling pattern like</p>
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">+ jcr:system
- + documentstore
- + bundlor
- + nt:file (oak:Unstructured)
- - pattern = ["jcr:content"]
-</pre></div></div>
+<li>jcr:system
+<ul>
+
+<li>documentstore
+<ul>
+
+<li>bundlor</li>
+<li>nt:file (oak:Unstructured)
+<ul>
+
+<li>pattern = [“jcr:content”]</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
<p>Would bundle the 2 nodes in nt:file node structure in same MongoDB Document</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">{
- "_id" : "2:/content/book.jpg",
+<div>
+<div>
+<pre class="source">{
+ "_id" : "2:/content/book.jpg",
"jcr:primaryType" : { "r15866f15753-0-1" : "\"nam:nt:file\""},
"jcr:content/jcr:primaryType" : { "r15866f15753-0-1" : "\"nam:nt:resource\""},
"_bin" : NumberLong(1),
@@ -432,13 +453,15 @@
"_modCount" : NumberLong(1)
}
</pre></div></div>
+
<p>So with bundling 1 nt:file would create 1 MongoDB Document. 10M nt:file instance would create 10M MongoDB documents instead of 20M (without bundling)</p></div>
<div class="section">
<h3><a name="Bundling_app:Asset"></a><a name="bundling-usage-file"></a> Bundling app:Asset</h3>
<p>Lets take a more complex content structure. Assume a nodetype <tt>app:Asset</tt> having following content</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content/banner.png
+<div>
+<div>
+<pre class="source">/content/banner.png
- jcr:primaryType = "app:Asset"
+ jcr:content
- jcr:primaryType = "app:AssetContent"
@@ -454,35 +477,49 @@
- jcr:data = ...
+ comments (nt:folder)
</pre></div></div>
-<p>Above structure has following characteristics</p>
+<p>Above structure has following characteristics</p>
<ul>
-
+
<li>It consist of <b>static structure</b> like ‘jcr:content’, ‘jcr:content/metadata’</li>
-
<li>It consist of <b>bounded structure</b> like ‘jcr:content/renditions’. Under renditions it can have max 5 type of nt:file node</li>
-
-<li>It has <b>unbounded relative nodes</b> like ‘jcr:content/comments’ and ‘jcr:content/metadata/xmp’. Nodes under these paths can have unbounded content</li>
-
+<li>It has <b>unbounded relative nodes</b> like ‘jcr:content/comments’ and ‘jcr:content/metadata/xmp’. Nodes under these paths can have unbounded content</li>
<li>Static and bounded structure take upto ~15 JCR Nodes (assuming 5 types of renditions)</li>
</ul>
-<p>So 1 asset ~ 15 JCR Nodes and ~ 15 MongoDB documents. Thus by default 10M assets would lead to 150M+ MongoDB Documents. Such a structure can make use of Node Bundling to reduce this storage ratio. </p>
+<p>So 1 asset ~ 15 JCR Nodes and ~ 15 MongoDB documents. Thus by default 10M assets would lead to 150M+ MongoDB Documents. Such a structure can make use of Node Bundling to reduce this storage ratio.</p>
<p>Lets define a bundling pattern like below</p>
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">+ jcr:system
- + documentstore
- + bundlor
- + nt:file (oak:Unstructured)
- - pattern = ["jcr:content"]
- + app:Asset
- - pattern = ["jcr:content/metadata", "jcr:content/renditions/**", "jcr:content"]
-</pre></div></div>
-<p>With this bundling pattern same app:Asset structure would be stored in 1 MongoDB Document excluding ‘comments’ and ‘xmp’ nodes</p>
+<li>jcr:system
+<ul>
+
+<li>documentstore
+<ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">{
+<li>bundlor</li>
+<li>nt:file (oak:Unstructured)
+<ul>
+
+<li>pattern = [“jcr:content”]</li>
+</ul>
+</li>
+<li>app:Asset
+<ul>
+
+<li>pattern = [“jcr:content/metadata”, “jcr:content/renditions/**”, “jcr:content”]</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+<p>With this bundling pattern same app:Asset structure would be stored in 1 MongoDB Document excluding ‘comments’ and ‘xmp’ nodes</p>
+<div>
+<div>
+<pre class="source">{
+
"_children": true,
"_modified": 1469081925,
"_id": "2:/test/book.jpg",
@@ -501,7 +538,7 @@
"jcr:content/metadata/:doc-self-path": {"r1560c1b3db8-0-1" : "\"str:jcr:content/metadata\""},
"jcr:content/metadata/status": {"r1560c1b3db8-0-1": "\"published\""},
"jcr:content/metadata/jcr:primaryType": {"r1560c1b3db8-0-1": "\"nam:oak:Unstructured\""},
-
+
//Relative node jcr:content/renditions
"jcr:content/renditions/:doc-self-path": {"r1560c1b3db8-0-1" : "\"str:jcr:content/renditions\""},
"jcr:content/renditions/jcr:primaryType": {"r1560c1b3db8-0-1": "\"nam:nt:folder\""},
@@ -515,7 +552,8 @@
"jcr:content/renditions/original/jcr:content/jcr:primaryType": {"r1560c1b3db8-0-1": "\"nam:nt:resource\""},
"jcr:content/renditions/original/jcr:content/jcr:data": {"r1560c1b3db8-0-1": "\"<data>\""},
}
-</pre></div></div></div></div>
+</pre></div></div>
+</div></div>
<div class="section">
<h2><a name="Design_Considerations"></a><a name="bundling-design-considerations"></a> Design Considerations</h2>
<p>While enabling bundling consider following points:</p>
@@ -530,14 +568,16 @@
<h2><a name="Benefits_and_Limitations"></a><a name="bundling-benefits-limits"></a> Benefits and Limitations</h2>
<div class="section">
<h3><a name="Benefits"></a><a name="bundling-benefits"></a> Benefits</h3>
-
<ul>
-
+
<li>
-<p><b>Reduced latency for traversal</b> - If you have an structure like aap:Asset and traversal is done it would involve lots of queries for child nodes as JCR level traversal is done to read any of the relative nodes like ’jcr:content/renditions. With bundling all those queries are avoided.</p></li>
-
+
+<p><b>Reduced latency for traversal</b> - If you have an structure like aap:Asset and traversal is done it would involve lots of queries for child nodes as JCR level traversal is done to read any of the relative nodes like ’jcr:content/renditions. With bundling all those queries are avoided.</p>
+</li>
<li>
-<p><b>Reduced number of Documents in persistent store</b> - Currently for a nodetype like app:Asset where 1 app:Asset = 15 JCR Nodes. If we have 10M assets then we would be consuming 150 M documents in MongoDB. With bundling this ratio can be reduced to say 1-5 then it would reduce actual number of documents in Mongo. Fewer documents means reduces size for _id and {_modified, _id} index. Reduced index size allows storing a lot more MongoDB documents as index size is key factor for sizing MongoDB setups.</p></li>
+
+<p><b>Reduced number of Documents in persistent store</b> - Currently for a nodetype like app:Asset where 1 app:Asset = 15 JCR Nodes. If we have 10M assets then we would be consuming 150 M documents in MongoDB. With bundling this ratio can be reduced to say 1-5 then it would reduce actual number of documents in Mongo. Fewer documents means reduces size for _id and {_modified, _id} index. Reduced index size allows storing a lot more MongoDB documents as index size is key factor for sizing MongoDB setups.</p>
+</li>
</ul></div>
<div class="section">
<h3><a name="Limitations"></a><a name="bundling-limits"></a> Limitations</h3>
Modified: jackrabbit/site/live/oak/docs/nodestore/document/secondary-store.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/document/secondary-store.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/document/secondary-store.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/document/secondary-store.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Secondary NodeStore</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -241,89 +241,71 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
- --><h1>Secondary NodeStore</h1>
-
+ -->
+<h1>Secondary NodeStore</h1>
<ul>
-
+
<li><a href="#secondary-node-store">Secondary NodeStore</a></li>
-
<li><a href="#read-flow">Read Flow</a></li>
-
<li><a href="#write-flow">Write Flow</a>
-
<ul>
-
+
<li><a href="#write-flow-local-changes">Local Changes</a></li>
-
<li><a href="#write-flow-external-changes">External Changes</a></li>
-
<li><a href="#write-flow-startup-sync">Startup Sync</a></li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="#usage">Setup </a></li>
-
<li><a href="#setup-considerations">Setup Considerations</a></li>
-
<li><a href="#administration">Administration</a>
-
<ul>
-
+
<li><a href="#secondary-store-maintenance">Maintenance</a></li>
-
<li><a href="#secondary-store-cluster">New Cluster Member</a></li>
- </ul></li>
+</ul>
+</li>
</ul>
<p><tt>@since Oak 1.6</tt> <tt>Experimental Feature</tt></p>
-<p>Compared to SegmentNodeStore DocumentNodeStore has higher latency for reads for the data not present in the cache. This happens due to multiple round trips required to serve a hierarchical read access over remote storage. For e.g. reading content of path <i>/content/assets/nature/sunrise.jpg</i> would require around 4 remote calls if the path content is not present in local cache. <a href="../persistent-cache.html">Persistent Cache</a> helped in improving this by enabling caching lot more content off heap compared to limited inmemory cache. </p>
+<p>Compared to SegmentNodeStore DocumentNodeStore has higher latency for reads for the data not present in the cache. This happens due to multiple round trips required to serve a hierarchical read access over remote storage. For e.g. reading content of path <i>/content/assets/nature/sunrise.jpg</i> would require around 4 remote calls if the path content is not present in local cache. <a href="../persistent-cache.html">Persistent Cache</a> helped in improving this by enabling caching lot more content off heap compared to limited inmemory cache.</p>
<p>With new <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1312">Secondary NodeStore</a> support its now possible to configure a SegmentNodeStore as a secondary store to store content under certain set of paths locally. SegmentNodeStore act a local copy of remote repository (secondary store) more like a local git repo which gets updated from primary store (remote Mongo storage) via observation. Writes are still routed to primary store but reads can be served from local secondary store.</p>
<p><img src="secondary-store.png" alt="Secondary Store Setup" /></p>
<p>In above setup 2 Oak Cluser nodes connect to same Mongo server. In each Oak instance a SegmentNodeStore is configured as secondary store. This store gets updated by observer.</p>
<p><b>Experimental Feature</b></p>
<p>This feature is currently experimental. Following feature item is currently pending</p>
-
<ul>
-
+
<li><a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-5352">OAK-5352</a> - Support for maintenance task for secondary NodeStore</li>
</ul>
<div class="section">
<h2><a name="Read_Flow"></a><a name="read-flow"></a> Read Flow</h2>
<p>Reading /a/b at revision r1 would happen like below</p>
-<p><img src="secondary-store-read.png" alt="Secondary Store Read Flow" /> </p>
+<p><img src="secondary-store-read.png" alt="Secondary Store Read Flow" /></p>
<p>Key points here</p>
-
<ul>
-
+
<li>Secondary NodeStore can be configured to only stored content under certain paths</li>
-
<li>Read would be first attempted from any configured secondary NodeStore.
-
<ol style="list-style-type: decimal">
-
-<li>Secondary NodeStore would check if it stores content for that path. Note that it can be configured with path inclusions</li>
-
+
+<li>Secondary NodeStore would check if it stores content for that path. Note that it can be configured with path inclusions</li>
<li>It then checks whether its root revision is later than revision at which read is being requested</li>
-
<li>If NodeState at given path and revision is found then its returned</li>
- </ol></li>
-
-<li>If read is not possible from secondary NodeStore then read is done from in memory which may in turn read from remote Mongo in case of cache miss</li>
-
-<li>If read is successful from Secondary NodeStore which is based on SegmentNodeStore then further child read from that path would be directly handled by SegmentNodeStore by passing DocumentNodeStore altogether. So if /a/b@r1 is found in secondary then read for /a/b/c@r1 would be directly handled by secondary store</li>
+</ol>
+</li>
+<li>If read is not possible from secondary NodeStore then read is done from in memory which may in turn read from remote Mongo in case of cache miss</li>
+<li>If read is successful from Secondary NodeStore which is based on SegmentNodeStore then further child read from that path would be directly handled by SegmentNodeStore by passing DocumentNodeStore altogether. So if /a/b@r1 is found in secondary then read for /a/b/c@r1 would be directly handled by secondary store</li>
</ul>
<p>Note that even if root revision of secondary store is lagging behind current head its possible that read for /a/b can be handled by secondary store if /a has not been modified recently. So those parts of repo which have not been recently modified would most likely be served from Secondary NodeStore and avoid remote calls to Mongo.</p></div>
<div class="section">
<h2><a name="Write_Flow"></a><a name="write-flow"></a> Write Flow</h2>
<p>Updates to secondary store happen in 3 ways</p>
-<p><img src="secondary-store-write.png" alt="Secondary Store Write Flow" /> </p>
+<p><img src="secondary-store-write.png" alt="Secondary Store Write Flow" /></p>
<p>Key points here</p>
-
<ul>
-
+
<li>Writes done by NodeStore caller i.e. JCR layer are always done on primary store i.e. Mongo</li>
-
<li>Secondary NodeStore is updated via Oak Observation support and NodeState diff</li>
-
-<li>Secondary NodeStore can be configured with path filter and then it would only be interested in changes for configured paths</li>
+<li>Secondary NodeStore can be configured with path filter and then it would only be interested in changes for configured paths</li>
</ul>
<div class="section">
<h3><a name="Local_Changes"></a><a name="write-flow-local-changes"></a> Local Changes</h3>
@@ -342,34 +324,34 @@
<p><b>1. Configure SegmentNodeStore in secondary role</b></p>
<p>Create an OSGi config file <tt>org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory-secondary.config</tt> with following content</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">role="secondary"
+<div>
+<div>
+<pre class="source">role="secondary"
</pre></div></div>
+
<p>This would create a SegmentNodeStore in secondary role and uses default <tt>segmentstore-secondary</tt> directory to store the segment files. Refer to <a href="../../osgi_config.html#config-SegmentNodeStoreService">config options</a> for more details. Note all the options for <tt>SegmentNodeStoreService</tt> are applicable for <tt>SegmentNodeStoreFactory</tt></p>
<p><b>2. Configure SecondaryStoreCacheService (optional)</b></p>
<p>By default secondary NodeStore would be activated based on previous config only. However it can be tweaked further by creating an OSGi config file <tt>org.apache.jackrabbit.oak.plugins.document.secondary.SecondaryStoreCacheService.config</tt></p>
-<div class="source">
-<div class="source"><pre class="prettyprint">includedPaths=[ \
+<div>
+<div>
+<pre class="source">includedPaths=[ \
"/libs", \
"/apps", \
"/content"
]
</pre></div></div>
+
<p>Above config would enable secondary NodeStore for paths ‘/libs, /apps and /content’</p></div>
<div class="section">
<h2><a name="Setup_Considerations"></a><a name="setup-considerations"></a> Setup Considerations</h2>
<p>While enabling secondary NodeStore feature following aspects needs to be considered</p>
-
<ul>
-
-<li>SegmentNodeStore used as secondary NodeStore would compete with system resource like memory along with in memory caches of DocumentNodeStore and Lucene index files. So system must have sufficient memory to for all these 3 components</li>
-
+
+<li>SegmentNodeStore used as secondary NodeStore would compete with system resource like memory along with in memory caches of DocumentNodeStore and Lucene index files. So system must have sufficient memory to for all these 3 components</li>
<li>SegmentNodeStore can be copied from any existing cluster node to a new node.</li>
-
-<li>If this is being enabled for existing setup then initial sync would take some time. So take that into account while planning to enable this feature</li>
-
-<li>For best performance include those paths of the repository which are accessed by end user. Specially those content paths where read to write ratio is high.</li>
+<li>If this is being enabled for existing setup then initial sync would take some time. So take that into account while planning to enable this feature</li>
+<li>For best performance include those paths of the repository which are accessed by end user. Specially those content paths where read to write ratio is high.</li>
</ul></div>
<div class="section">
<h2><a name="Administration"></a><a name="administration"></a> Administration</h2>
Modified: jackrabbit/site/live/oak/docs/nodestore/document/upgrade.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/document/upgrade.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/document/upgrade.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/document/upgrade.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – DocumentNodeStore upgrade instructions</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,76 +240,72 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
- --><h1>DocumentNodeStore upgrade instructions</h1>
+ -->
+<h1>DocumentNodeStore upgrade instructions</h1>
<p>In general Oak aims to provide a smooth upgrade path that allows a new version of Oak to simply run on data written by an older version of Oak. In some cases additional manual steps are needed or recommended to ensure performance and reduce downtime of a system to a minimum.</p>
<div class="section">
<h2><a name="Upgrade_to_1.8"></a><a name="a1.8"></a>Upgrade to 1.8</h2>
<p>Oak 1.8 introduced some changes in the DocumentNodeStore that require an one-time sweep of the DocumentStore per cluster node. This sweep is triggered automatically on startup when Oak detects an upgrade from an older version. Depending on the size of the repository, the sweep operation may take some time and prolong the downtime of the system during an upgrade. Alternatively, the one-time sweep operation can also be triggered for an inactive cluster node with the oak-run tool while the remaining cluster nodes are active and in use by the application. This is the recommended approach because it minimizes downtime.</p>
<div class="section">
<h3><a name="Prerequisites"></a>Prerequisites</h3>
-
<ul>
-
+
<li>Create a backup of the system</li>
-
<li>The new Oak version and/or application that bundles or uses Oak</li>
-
<li>The oak-run tool in the same version as used by the updated application</li>
-
<li>A successful test run of below steps on a clone of the production system before they are applied to production.</li>
</ul></div>
<div class="section">
<h3><a name="Instructions"></a>Instructions</h3>
<p>The following instructions assume a cluster with two nodes C1 and C2 running on Oak 1.6 or older.</p>
-
<ul>
-
-<li>
-<p>Remove documents potentially created by <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-4345">OAK-4345</a>. The issue only affected deployments based on MongoDB. Connect to the database with a MongoDB shell and then execute:</p>
-
-<div class="source">
-<div class="source"><pre class="prettyprint">> db.nodes.remove({_id:{$type:7}})
-</pre></div></div></li>
-
+
+<li>Remove documents potentially created by <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-4345">OAK-4345</a>. The issue only affected deployments based on MongoDB. Connect to the database with a MongoDB shell and then execute:
+
+<div>
+<div>
+<pre class="source">> db.nodes.remove({_id:{$type:7}})
+</pre></div></div>
+</li>
<li>Stop cluster node C1. If possible, the cluster node should be shut down gracefully because the next step can only be executed when C1 is considered inactive. A recovery of C1 is otherwise necessary if it is forcefully killed. This happens automatically when there are other active nodes in the cluster, but is only initiated after the lease of C1 timed out. The DocumentNodeStore MBean of an active cluster node can be inspected to find out whether some other cluster node is considered inactive (see InactiveClusterNodes attribute).</li>
-
-<li>
-<p>Run the revisions sweep command using the oak-run tool for C1. A sweep can only run on an inactive cluster node, otherwise the command will refuse to run. Assuming C1 used clusterId 1, the command line would look like this:</p>
-
-<div class="source">
-<div class="source"><pre class="prettyprint">> java -Xmx2g -jar oak-run-1.8.0.jar revisions mongodb://localhost:27017/oak sweep --clusterId 1
+<li>Run the revisions sweep command using the oak-run tool for C1. A sweep can only run on an inactive cluster node, otherwise the command will refuse to run. Assuming C1 used clusterId 1, the command line would look like this:
+
+<div>
+<div>
+<pre class="source">> java -Xmx2g -jar oak-run-1.8.0.jar revisions mongodb://localhost:27017/oak sweep --clusterId 1
</pre></div></div>
+
<p>For larger repositories it is recommended to be more generous with the cache size, which will speed up the sweep operation: <tt>--cacheSize 1024</tt> More detailed progress is available when <tt>--verbose</tt> is added.</p>
<p>Once finished the tool will print a summary:</p>
-
-<div class="source">
-<div class="source"><pre class="prettyprint">Updated sweep revision to r15d12cb1836-0-1. Branch commit markers added to 8907 documents. Reverted uncommitted changes on 19 documents. (7.94 min)
-</pre></div></div></li>
-
+
+<div>
+<div>
+<pre class="source">Updated sweep revision to r15d12cb1836-0-1. Branch commit markers added to 8907 documents. Reverted uncommitted changes on 19 documents. (7.94 min)
+</pre></div></div>
+</li>
<li>
-<p>C1 is now ready for an upgrade to Oak 1.8. </p></li>
-
+
+<p>C1 is now ready for an upgrade to Oak 1.8.</p>
+</li>
<li>Stop cluster node C2. This is when downtime of the system starts.</li>
-
<li>Unlock the repository for an upgrade to Oak 1.8. This step is only possible when <i>all</i> nodes of a cluster are inactive. See also <a href="../documentmk.html">unlock upgrade</a> section. At this point the previous Oak version cannot use the DocumentStore anymore. A restore from the backup will be necessary should any of the following steps fail for some reason and the upgrade needs to be rolled back.</li>
-
<li>Start cluster node C1 with the new version of Oak and the application.</li>
-
-<li>
-<p>Run the revisions sweep command using the oak-run tool for C2 (assuming it used clusterId 2):</p>
-
-<div class="source">
-<div class="source"><pre class="prettyprint"> > java -Xmx2g -jar oak-run-1.8.0.jar revisions mongodb://localhost:27017/oak sweep --clusterId 2
-</pre></div></div></li>
-
-<li>
-<p>Start cluster node C2 with the new version of Oak and the application.</p></li>
-
+<li>Run the revisions sweep command using the oak-run tool for C2 (assuming it used clusterId 2):
+
+<div>
+<div>
+<pre class="source"> > java -Xmx2g -jar oak-run-1.8.0.jar revisions mongodb://localhost:27017/oak sweep --clusterId 2
+</pre></div></div>
+</li>
<li>
-<p>Create recommended indexes in MongoDB and remove old ones. For a more efficient Revision GC, the existing indexes on <tt>_deletedOnce</tt> and <tt>_sdType</tt> should be replaced. Please note, the partial index on <tt>_deletedOnce</tt> and <tt>_modified</tt> requires at least MongoDB 3.2.</p>
-
-<div class="source">
-<div class="source"><pre class="prettyprint">> db.nodes.createIndex({_sdType:1, _sdMaxRevTime:1}, {sparse:true})
+
+<p>Start cluster node C2 with the new version of Oak and the application.</p>
+</li>
+<li>Create recommended indexes in MongoDB and remove old ones. For a more efficient Revision GC, the existing indexes on <tt>_deletedOnce</tt> and <tt>_sdType</tt> should be replaced. Please note, the partial index on <tt>_deletedOnce</tt> and <tt>_modified</tt> requires at least MongoDB 3.2.
+
+<div>
+<div>
+<pre class="source">> db.nodes.createIndex({_sdType:1, _sdMaxRevTime:1}, {sparse:true})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 5,
@@ -328,6 +324,7 @@
> db.nodes.dropIndex("_deletedOnce_1")
{ "nIndexesWas" : 6, "ok" : 1 }
</pre></div></div>
+
<p>See also instructions how to <a class="externalLink" href="https://docs.mongodb.com/manual/tutorial/build-indexes-on-replica-sets/#index-building-replica-sets">build indexes on a replica set</a> to minimize impact on the system.</p></li>
</ul></div></div>
</div>