diff --git a/content/enterprise_influxdb/v1.8/administration/config-data-nodes.md b/content/enterprise_influxdb/v1.8/administration/config-data-nodes.md index c7552c46e..28c4e5e7e 100644 --- a/content/enterprise_influxdb/v1.8/administration/config-data-nodes.md +++ b/content/enterprise_influxdb/v1.8/administration/config-data-nodes.md @@ -398,22 +398,17 @@ so it is unlikely that changing this value will measurably improve performance b Environment variable: `INFLUXDB_CLUSTER_POOL_MAX_IDLE_STREAMS` -#### `allow-out-of-order = "false"` +#### allow-out-of-order = "false" -By default, this option is set to false and writes are processed in the order that they are received. This means -if any points are in the hinted handoff (HH) queue for a shard, all incoming points must go into the HH queue. +By default, this option is set to false and writes are processed in the order that they are received. This means if any points are in the hinted handoff (HH) queue for a shard, all incoming points must go into the HH queue. -If this option is set to true, writes are allowed to process in an order that differs from the order they were received. -This can reduce the time required to drain the HH queue and increase throughput during recovery. -**Do not enable if your use case involves updating points.** Updating a point means the measurement name, tag keys, -and timestamp are the same as a previous write and only the value is different. +If true, writes may process in a different order than they were received. This can reduce the time required to drain the HH queue and increase throughput during recovery. -Allowing out of order writes when updating points may cause incorrect values. For example, -if the point `cpu v=1.0 1234` arrives on `node1` and attempts to replicate on `node2` -but `node2` is down, `node1` writes the point to its local HH queue. If `node2` comes back online -and a new point `cpu v=20. 1234` arrives at `node1` and updates the original point, the updated point -is sent to `node2` (bypassing the HH queue). Because the updated point arrives at `node2` before the -original point, and second point value is stored before the original point value. +**Do not enable if your use case involves updating points, which may cause points to be overwritten.** To overwrite an existing point, the measurement name, tag keys and values (if the point includes tags), field keys, and timestamp all have to be the same as a previous write. + +For example, if you have two points with the same measurement (`cpu`), field key (`v`), and timestamp (`1234`), the following could happen: + +Point 1 (`cpu v=1.0 1234`) arrives at `node1`, attempts to replicate on `node2`, and finds `node2` is down, so point 1 goes to the local HH queue. Now, `node2` comes back online and point 2 `cpu v=20. 1234` arrives at `node1`, overwrites point 1, and is written to `node2` (bypassing the HH queue). Because the point 2 arrives at `node2` before point 1, point 2 is stored before point 1. Environment variable: `INFLUXDB_CLUSTER_ALLOW_OUT_OF_ORDER`