(Doc+) How to resolve shards >50GB (elastic#111254)

* (Doc+) How to resolve shards >50GB --------- Co-authored-by: Ievgen Degtiarenko <[email protected]>
stefnestor · Jul 25, 2024 · 54a9d98 · 54a9d98
1 parent 531f029
commit 54a9d98
Showing 1 changed file with 27 additions and 3 deletions.
diff --git a/docs/reference/how-to/size-your-shards.asciidoc b/docs/reference/how-to/size-your-shards.asciidoc
@@ -152,9 +152,10 @@ same data. However, very large shards can also cause slower searches and will
 take longer to recover after a failure.
 
 There is no hard limit on the physical size of a shard, and each shard can in
-theory contain up to just over two billion documents. However, experience shows
-that shards between 10GB and 50GB typically work well for many use cases, as
-long as the per-shard document count is kept below 200 million.
+theory contain up to <<troubleshooting-max-docs-limit,just over two billion 
+documents>>. However, experience shows that shards between 10GB and 50GB 
+typically work well for many use cases, as long as the per-shard document count 
+is kept below 200 million.
 
 You may be able to use larger shards depending on your network and use case,
 and smaller shards may be appropriate for
@@ -184,6 +185,29 @@ index                                 prirep shard store
 // TESTRESPONSE[s/\.ds-my-data-stream-2099\.05\.06-000001/my-index-000001/]
 // TESTRESPONSE[s/50gb/.*/]
 
+If an index's shard is experiencing degraded performance from surpassing the 
+recommended 50GB size, you may consider fixing the index's shards' sizing. 
+Shards are immutable and therefore their size is fixed in place, 
+so indices must be copied with corrected settings. This requires first ensuring 
+sufficient disk to copy the data. Afterwards, you can copy the index's data 
+with corrected settings via one of the following options:
+
+* running <<indices-split-index,Split Index>> to increase number of primary 
+shards 
+
+* creating a destination index with corrected settings and then running 
+<<docs-reindex,Reindex>> 
+
+Kindly note performing a <<restore-snapshot-api,Restore Snapshot>> and/or 
+<<indices-clone-index,Clone Index>> would be insufficient to resolve shards' 
+sizing. 
+
+Once a source index's data is copied into its destination index, the source 
+index can be <<indices-delete-index,removed>>. You may then consider setting 
+<<indices-add-alias,Create Alias>> against the destination index for the source 
+index's name to point to it for continuity. 
+
+
 [discrete]
 [[shard-count-recommendation]]
 ==== Master-eligible nodes should have at least 1GB of heap per 3000 indices