You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/shared/v3-core-get-started/_index.md
+30-2Lines changed: 30 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -377,8 +377,36 @@ For more information, see [diskless architecture](#diskless-architecture).
377
377
> [!Note]
378
378
> ##### Write requests return after WAL flush
379
379
>
380
-
> Because InfluxDB sends a write response after the WAL file has been flushed to the configured object store (default is every second), individual write requests might not complete quickly, but you can make many concurrent requests to achieve higher total throughput.
381
-
> Future enhancements will include an API parameter that lets requests return without waiting for the WAL flush.
380
+
> By default, InfluxDB acknowledges writes after flushing the WAL file to the Object store (occurring every second). For high throughput, you can send multiple concurrent write requests.
381
+
>
382
+
> To reduce the latency of writes, use the [`no_sync` write option](#no-sync-write-option), which acknowledges writes _before_ WAL persistence completes.
383
+
384
+
##### No sync write option
385
+
386
+
The `no_sync` write option reduces latency by acknowledging write requests before WAL persistence completes. When set to `true`, InfluxDB validates the data, writes the data to the WAL, and then immediately confirms the write, without waiting for persistence to the Object store.
387
+
388
+
Using `no_sync=true` is best when prioritizing high-throughput writes over absolute durability.
389
+
390
+
- Default behavior (`no_sync=false`): Waits for data to be written to the Object store before acknowledging the write. Reduces the risk of data loss, but increases the latency of the response.
391
+
- With `no_sync=true`: Reduces write latency, but increases the risk of data loss in case of a crash before WAL persistence.
392
+
393
+
###### Immediate write using the HTTP API
394
+
395
+
The `no_sync` parameter controls when writes are acknowledged--for example:
0 commit comments