getting-started.asciidoc 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343
  1. [role="xpack"]
  2. [testenv="platinum"]
  3. [[ccr-getting-started]]
  4. === Tutorial: Set up {ccr}
  5. ++++
  6. <titleabbrev>Set up {ccr}</titleabbrev>
  7. ++++
  8. ////
  9. [source,console]
  10. ----
  11. PUT /server-metrics
  12. {
  13. "settings" : {
  14. "index" : {
  15. "number_of_shards" : 1,
  16. "number_of_replicas" : 0
  17. }
  18. },
  19. "mappings" : {
  20. "properties" : {
  21. "@timestamp" : {
  22. "type" : "date"
  23. },
  24. "accept" : {
  25. "type" : "long"
  26. },
  27. "deny" : {
  28. "type" : "long"
  29. },
  30. "host" : {
  31. "type" : "keyword"
  32. },
  33. "response" : {
  34. "type" : "float"
  35. },
  36. "service" : {
  37. "type" : "keyword"
  38. },
  39. "total" : {
  40. "type" : "long"
  41. }
  42. }
  43. }
  44. }
  45. ----
  46. // TESTSETUP
  47. ////
  48. Use this guide to set up {ccr} (CCR) between clusters in two
  49. datacenters. Replicating your data across datacenters provides several benefits:
  50. * Brings data closer to your users or application server to reduce latency and
  51. response time
  52. * Provides your mission-critical applications with the tolerance to withstand datacenter or region outages
  53. In this guide, you'll learn how to:
  54. * Configure a <<modules-remote-clusters,remote cluster>> with a leader index
  55. * Create a follower index on a local cluster
  56. * Create an auto-follow pattern to automatically follow time series indices
  57. that are periodically created in a remote cluster
  58. You can manually create follower indices to replicate specific indices on a
  59. remote cluster, or configure auto-follow patterns to replicate rolling time series indices.
  60. TIP: If you want to replicate data across clusters in the cloud, you can
  61. link:{cloud}/ec-enable-ccs.html[configure remote clusters on {ess}]. Then, you
  62. can <<modules-cross-cluster-search,search across clusters>> and set up {ccr}.
  63. video::https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt994089f5e841ad69/5f6265de6f40ab4648b5cf9b/ccr-setup-video-edited.mp4[width=700, height=500, options="autoplay,loop"]
  64. [[ccr-getting-started-prerequisites]]
  65. ==== Prerequisites
  66. To complete this tutorial, you need:
  67. * A license on both clusters that includes {ccr}. {kibana-ref}/managing-licenses.html[Activate a free 30-day trial].
  68. * The `read_ccr` cluster privilege and `monitor` and `read` privileges
  69. for the leader index on the remote cluster. <<stack-management-ccr-remote,Configure remote cluster privileges>>.
  70. * The `manage_ccr` cluster privilege and `monitor`, `read`, `write` and
  71. `manage_follow_index` privileges to configure remote clusters and follower
  72. indices on the local cluster. <<stack-management-ccr-local,Configure local cluster privileges>>.
  73. * An index on the remote cluster that contains the data you want to replicate.
  74. This tutorial uses the sample eCommerce orders data set.
  75. {kibana-ref}/get-started.html#gs-get-data-into-kibana[Load sample data].
  76. * In the local cluster, all nodes with the `master` <<node-roles,node role>> must
  77. also have the <<remote-node,`remote_cluster_client`>> role. The local cluster
  78. must also have at least one node with both a data role and the
  79. <<remote-node,`remote_cluster_client`>> role. Individual tasks for coordinating
  80. replication scale based on the number of data nodes with the
  81. `remote_cluster_client` role in the local cluster.
  82. [[ccr-getting-started-remote-cluster]]
  83. ==== Connect to a remote cluster
  84. To replicate an index on a remote cluster (Cluster A) to a local cluster (Cluster B), you configure Cluster A as a remote on Cluster B.
  85. image::images/ccr-tutorial-clusters.png[ClusterA contains the leader index and ClusterB contains the follower index]
  86. To configure a remote cluster from Stack Management in {kib}:
  87. . Select *Remote Clusters* from the side navigation.
  88. . Specify the IP address or host name of the remote cluster (ClusterB),
  89. followed by the transport port of the remote cluster (defaults to `9300`). For
  90. example, `192.168.1.1:9300`.
  91. [role="screenshot"]
  92. image::images/ccr-add-remote-cluster.png["The Add remote clusters page in {kib}"]
  93. [%collapsible]
  94. .API example
  95. ====
  96. Use the <<cluster-update-settings,cluster update settings API>> to add a remote cluster:
  97. [source,console]
  98. --------------------------------------------------
  99. PUT /_cluster/settings
  100. {
  101. "persistent" : {
  102. "cluster" : {
  103. "remote" : {
  104. "leader" : {
  105. "seeds" : [
  106. "127.0.0.1:9300" <1>
  107. ]
  108. }
  109. }
  110. }
  111. }
  112. }
  113. --------------------------------------------------
  114. // TEST[setup:host]
  115. // TEST[s/127.0.0.1:9300/\${transport_host}/]
  116. <1> Specifies the hostname and transport port of a seed node in the remote
  117. cluster.
  118. You can verify that the local cluster is successfully connected to the remote
  119. cluster.
  120. [source,console]
  121. --------------------------------------------------
  122. GET /_remote/info
  123. --------------------------------------------------
  124. // TEST[continued]
  125. The API will respond by showing that the local cluster is connected to the
  126. remote cluster.
  127. [source,console-result]
  128. --------------------------------------------------
  129. {
  130. "leader" : {
  131. "seeds" : [
  132. "127.0.0.1:9300"
  133. ],
  134. "connected" : true, <1>
  135. "num_nodes_connected" : 1, <2>
  136. "max_connections_per_cluster" : 3,
  137. "initial_connect_timeout" : "30s",
  138. "skip_unavailable" : false,
  139. "mode" : "sniff"
  140. }
  141. }
  142. --------------------------------------------------
  143. // TESTRESPONSE[s/127.0.0.1:9300/$body.leader.seeds.0/]
  144. // TEST[s/"connected" : true/"connected" : $body.leader.connected/]
  145. // TEST[s/"num_nodes_connected" : 1/"num_nodes_connected" : $body.leader.num_nodes_connected/]
  146. <1> This shows the local cluster is connected to the remote cluster with cluster
  147. alias `leader`
  148. <2> This shows the number of nodes in the remote cluster the local cluster is
  149. connected to.
  150. ====
  151. [[ccr-enable-soft-deletes]]
  152. ==== Enable soft deletes on leader indices
  153. To follow an index, it must have been created with
  154. <<ccr-leader-requirements,soft deletes>> enabled. If the index doesn’t have
  155. soft deletes enabled, you must reindex it and use the new index as the leader
  156. index. Soft deletes are enabled by default on new indices
  157. created with {es} 7.0.0 and later.
  158. [[ccr-getting-started-follower-index]]
  159. ==== Create a follower index to replicate a specific index
  160. When you create a follower index, you reference the remote cluster and the
  161. leader index in your remote cluster.
  162. To create a follower index from Stack Management in {kib}:
  163. . Select *Cross-Cluster Replication* in the side navigation and choose the
  164. *Follower Indices* tab.
  165. . Choose the cluster (ClusterA) containing the leader index you want to
  166. replicate.
  167. . Enter the name of the leader index, which is
  168. `kibana_sample_data_ecommerce` if you are following the tutorial.
  169. . Enter a name for your follower index, such as `follower-kibana-sample-data`.
  170. image::images/ccr-add-follower-index.png["Adding a follower index named server-metrics in {kib}"]
  171. {es} initializes the follower using the
  172. <<ccr-remote-recovery, remote recovery>>
  173. process, which transfers the existing Lucene segment files from the leader
  174. index to the follower index. The index status changes to *Paused*. When the
  175. remote recovery process is complete, the index following begins and the status
  176. changes to *Active*.
  177. When you index documents into your leader index, {es} replicates the documents
  178. in the follower index.
  179. [role="screenshot"]
  180. image::images/ccr-follower-index.png["The Cross-Cluster Replication page in {kib}"]
  181. [%collapsible]
  182. .API example
  183. ====
  184. Use the <<ccr-put-follow,create follower API>> to create follower indices.
  185. When you create a follower index, you must reference the remote cluster and the
  186. leader index that you created in the
  187. remote cluster.
  188. When initiating the follower request, the response returns before the
  189. <<ccr-remote-recovery, remote recovery>> process completes. To wait for the process
  190. to complete, add the `wait_for_active_shards` parameter to your request.
  191. [source,console]
  192. --------------------------------------------------
  193. PUT /server-metrics-follower/_ccr/follow?wait_for_active_shards=1
  194. {
  195. "remote_cluster" : "leader",
  196. "leader_index" : "server-metrics"
  197. }
  198. --------------------------------------------------
  199. // TEST[continued]
  200. //////////////////////////
  201. [source,console-result]
  202. --------------------------------------------------
  203. {
  204. "follow_index_created" : true,
  205. "follow_index_shards_acked" : true,
  206. "index_following_started" : true
  207. }
  208. --------------------------------------------------
  209. //////////////////////////
  210. Use the
  211. <<ccr-get-follow-stats,get follower stats API>> to inspect the status of
  212. replication
  213. //////////////////////////
  214. [source,console]
  215. --------------------------------------------------
  216. POST /server-metrics-follower/_ccr/pause_follow
  217. POST /server-metrics-follower/_close
  218. POST /server-metrics-follower/_ccr/unfollow
  219. --------------------------------------------------
  220. // TEST[continued]
  221. //////////////////////////
  222. ====
  223. [[ccr-getting-started-auto-follow]]
  224. ==== Create an auto-follow pattern to replicate time series indices
  225. You use <<ccr-auto-follow,auto-follow patterns>> to automatically create new
  226. followers for rolling time series indices. Whenever the name of a new index on
  227. the remote cluster matches the auto-follow pattern, a corresponding follower
  228. index is added to the local cluster.
  229. An auto-follow pattern specifies the remote cluster you want to replicate from,
  230. and one or more index patterns that specify the rolling time series indices you
  231. want to replicate.
  232. // tag::ccr-create-auto-follow-pattern-tag[]
  233. To create an auto-follow pattern from Stack Management in {kib}:
  234. . Select *Cross Cluster Replication* in the side navigation and choose the
  235. *Auto-follow patterns* tab.
  236. . Enter a name for the auto-follow pattern, such as `beats`.
  237. . Choose the remote cluster that contains the index you want to replicate,
  238. which in the example scenario is Cluster A.
  239. . Enter one or more index patterns that identify the indices you want to
  240. replicate from the remote cluster. For example, enter
  241. `metricbeat-* packetbeat-*` to automatically create followers for {metricbeat} and {packetbeat} indices.
  242. . Enter *follower-* as the prefix to apply to the names of the follower indices so
  243. you can more easily identify replicated indices.
  244. As new indices matching these patterns are
  245. created on the remote, {es} automatically replicates them to local follower indices.
  246. [role="screenshot"]
  247. image::images/auto-follow-patterns.png["The Auto-follow patterns page in {kib}"]
  248. // end::ccr-create-auto-follow-pattern-tag[]
  249. [%collapsible]
  250. .API example
  251. ====
  252. Use the <<ccr-put-auto-follow-pattern,create auto-follow pattern API>> to
  253. configure auto-follow patterns.
  254. [source,console]
  255. --------------------------------------------------
  256. PUT /_ccr/auto_follow/beats
  257. {
  258. "remote_cluster" : "leader",
  259. "leader_index_patterns" :
  260. [
  261. "metricbeat-*", <1>
  262. "packetbeat-*" <2>
  263. ],
  264. "follow_index_pattern" : "{{leader_index}}-copy" <3>
  265. }
  266. --------------------------------------------------
  267. // TEST[continued]
  268. <1> Automatically follow new {metricbeat} indices.
  269. <2> Automatically follow new {packetbeat} indices.
  270. <3> The name of the follower index is derived from the name of the leader index
  271. by adding the suffix `-copy` to the name of the leader index.
  272. //////////////////////////
  273. [source,console-result]
  274. --------------------------------------------------
  275. {
  276. "acknowledged" : true
  277. }
  278. --------------------------------------------------
  279. //////////////////////////
  280. //////////////////////////
  281. [source,console]
  282. --------------------------------------------------
  283. DELETE /_ccr/auto_follow/beats
  284. --------------------------------------------------
  285. // TEST[continued]
  286. //////////////////////////
  287. ====