### 创建、索引、删除文档 Create, index and delete requests are _write_ operations, which must besuccessfully completed on the primary shard before they can be copied to anyassociated replica shards. [[img-distrib-write]].Creating, indexing or deleting a single documentimage::images/04-02_write.png["Creating, indexing or deleting a single document"] Below we list the sequence of steps necessary to successfully create, index ordelete a document on both the primary and any replica shards, as depicted in<>: 1. The client sends a create, index or delete request to `Node_1`. 1. The node uses the document's `_id` to determine that the documentbelongs to shard `0`. It forwards the request to `Node 3`,where the primary copy of shard `0` is currently allocated. 1. `Node 3` executes the request on the primary shard. If it is successful,it forwards the request in parallel to the replica shards on `Node 1` and`Node 2`. Once all of the replica shards report success, `Node 3` reportssuccess to the requesting node, which reports success to the client. By the time the client receives a successful response, the document change hasbeen executed on the primary shard and on all replica shards. Your change issafe. There are a number of optional request parameters which allow you to influencethis process, possibly increasing performance at the cost of data security.These options are seldom used because Elasticsearch is already fast, but theyare explained here for the sake of completeness. `replication`:: ### + The default value for replication is `sync`. This causes the primary shard towait for successful responses from the replica shards before returning. If you set `replication` to `async`, then it will return success to the clientas soon as the request has been executed on the primary shard. It will stillforward the request to the replicas, but you will not know if the replicassucceeded or not. It is advisable to use the default `sync` replication as it is possible tooverload Elasticsearch by sending too many requests without waiting for their ### completion. `consistency`:: ### + By default, the primary shard requires a _quorum_ or majority of shard copies(where a shard copy can be a primary or a replica shard) to be availablebefore even attempting a write operation. This is to prevent writing data to the``wrong side'' of a network partition. A quorum is defined as: ~~~ int( (primary + number_of_replicas) / 2 ) + 1 ~~~ The allowed values for `consistency` are `one` (just the primary shard), `all`(the primary and all replicas) or the default `quorum` or majority of shardcopies. Note that the `number_of_replicas` is the number of replicas _specified_ inthe index settings, not the number of replicas that are currently active. Ifyou have specified that an index should have 3 replicas then a quorum wouldbe: ~~~ int( (primary + 3 replicas) / 2 ) + 1 = 3 ~~~ But if you only start 2 nodes, then there will be insufficient active shardcopies to satisfy the quorum and you will be unable to index or delete anydocuments. -- `timeout`:: What happens if insufficient shard copies are available? Elasticsearch waits,in the hope that more shards will appear. By default it will wait up to oneminute. If you need to, you can use the `timeout` parameter to make it abortsooner: `100` is 100 milliseconds, `30s` is 30 seconds. # [NOTE] A new index has `1` replica by default, which means that two active shardcopies _should_ be required in order to satisfy the need for a `quorum`.However, these default settings would prevent us from doing anything usefulwith a single-node cluster. To avoid this problem, the requirement for # a quorum is only enforced when `number_of_replicas` is greater than `1`.