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-enterprise-get-started/_index.md
+54-11Lines changed: 54 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -217,24 +217,22 @@ InfluxDB is a schema-on-write database. You can start writing data and InfluxDB
217
217
After a schema is created, InfluxDB validates future write requests against it before accepting the data.
218
218
Subsequent requests can add new fields on-the-fly, but can't add new tags.
219
219
220
-
**Note**: write requests to the database _don't_ returnuntil a WAL file has been flushed to the configured object store, which by default happens once per second.
221
-
This means that individual write requests may not complete quickly, but you can make many concurrent requests to get higher total throughput. In the future, we will add an API parameter to make requests that do not waitfor the WAL flush to return.
222
-
223
220
The database has three write API endpoints that respond to HTTP `POST` requests:
{{% product-name %}} provides the `/write_lp` and `/api/v2` endpoints for backward compatibility with clients that can write data to previous versions of InfluxDB.
226
+
{{% product-name %}} provides the `/write` and `/api/v2/write` endpoints for backward compatibility with clients that can write data to previous versions of InfluxDB.
230
227
However, these APIs differ from the APIs in the previous versions in the following ways:
231
228
232
229
- Tags in a table (measurement) are _immutable_
233
230
- A tag and a field can't have the same name within a table.
234
231
235
-
The `/api/v3/write_lp` endpoint accepts the same line protocol syntax as previous versions, and brings new functionality that lets you accept or reject partial writes using the `accept_partial` parameter (`true` is default).
232
+
{{% product-name %}} adds the `/api/v3/write_lp` endpoint, which accepts the same line protocol syntax as previous versions, and supports an `?accept_partial=<BOOLEAN>` parameter, which
233
+
lets you accept or reject partial writes (default is `true`).
236
234
237
-
The following code block is an example of [line protocol](/influxdb3/enterprise/reference/syntax/line-protocol/), which shows the table name followed by tags, which are an ordered, comma-separated list of key/value pairs where the values are strings, followed by a comma-separated list of key/value pairs that are the fields, and ending with an optional timestamp. The timestamp by default is a nanosecond epoch, but you can specify a different precision through the `precision` query parameter.
235
+
The following code block is an example of [line protocol](/influxdb3/core/reference/syntax/line-protocol/), which shows the table name followed by tags, which are an ordered, comma-separated list of key/value pairs where the values are strings, followed by a comma-separated list of key/value pairs that are the fields, and ending with an optional timestamp. The timestamp by default is a nanosecond epoch, but you can specify a different precision through the `precision` query parameter.
The written data goes into WAL files, created once per second, and into an in-memory queryable buffer. Later, InfluxDB snapshots the WAL and persists the data into object storage as Parquet files.
255
-
We'll cover the [diskless architecture](#diskless-architecture) later in this document.
252
+
The following examples show how to write data using `curl` and the `/api/3/write_lp` HTTP endpoint.
253
+
To show the difference between accepting and rejecting partial writes, `line 2`in the example contains a `string` value for a `float` field (`temp=hi`).
254
+
255
+
##### Partial write of line protocol occurred
256
+
257
+
With `accept_partial=true`:
258
+
259
+
```
260
+
* upload completely sent off: 59 bytes
261
+
< HTTP/1.1 400 Bad Request
262
+
< transfer-encoding: chunked
263
+
< date: Wed, 15 Jan 2025 19:35:36 GMT
264
+
<
265
+
* Connection #0 to host localhost left intact
266
+
{"error":"partial write of line protocol occurred","data":[{"original_line":"dquote> home,room=Sunroom temp=hi","line_number":2,"error_message":"No fields were provided"}]}%
267
+
```
268
+
269
+
The response is an HTTP error (`400`) status, and the response body contains `partial write of line protocol occurred` and details about the problem line.
{"error":"parsing failed for write_lp endpoint","data":{"original_line":"dquote> home,room=Sunroom temp=hi","line_number":2,"error_message":"No fields were provided"}}%
285
+
```
286
+
287
+
The response is an HTTP error (`400`) status, and the response body contains `parsing failed for write_lp endpoint` and details about the problem line.
288
+
289
+
##### Data durability
290
+
291
+
Written data goes into WAL files, created once per second, and into an in-memory queryable buffer. Later, InfluxDB snapshots the WAL and persists the data into object storage as Parquet files.
292
+
We cover the [diskless architecture](#diskless-architecture) later in this guide.
293
+
294
+
> [!Note]
295
+
>##### Write requests return after WAL flush
296
+
> Write requests to the database _don't_ return until a WAL file has been flushed to the configured object store, which by default happens once per second.
297
+
> Individual write requests might not complete quickly, but you can make many concurrent requests to get higher total throughput.
298
+
> In the future, we will add an API parameter that lets requests return without waiting for the WAL flush.
0 commit comments