Skip to content

Commit ab19dc2

Browse files
leto-bleto-b
authored
remove bidirectional examples in table model apache (#852)
* remove bidirectional examples in table model apache * remove double-living from apache
1 parent f530185 commit ab19dc2

8 files changed

Lines changed: 18 additions & 169 deletions

File tree

‎src/UserGuide/Master/Table/User-Manual/Data-Sync_apache.md‎

Lines changed: 5 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -292,41 +292,7 @@ WITH SINK (
292292
'node-urls' = '127.0.0.1:6668' -- The URL of the DataNode's data service port in the target IoTDB instance.
293293
)
294294
```
295-
### 3.3 Bidirectional Data Transmission
296-
297-
This example demonstrates a scenario where two IoTDB instances act as dual-active systems. The data pipeline is shown below:
298-
299-
![](/img/e3.png)
300-
301-
To avoid infinite data loops, the `source.mode.double-living` parameter must be set to `true` on both IoTDB A and B, indicating that data forwarded from another pipe will not be retransmitted.
302-
303-
SQL Example: On IoTDB A:
304-
305-
```SQL
306-
CREATE PIPE AB
307-
WITH SOURCE (
308-
'source.mode.double-living' = 'true' -- Do not forward data from other pipes
309-
)
310-
WITH SINK (
311-
'sink' = 'iotdb-thrift-sink',
312-
'node-urls' = '127.0.0.1:6668' -- URL of the DataNode service port on the target IoTDB
313-
)
314-
```
315-
316-
On IoTDB B:
317-
318-
```SQL
319-
CREATE PIPE BA
320-
WITH SOURCE (
321-
'source.mode.double-living' = 'true' -- Do not forward data from other pipes
322-
)
323-
WITH SINK (
324-
'sink' = 'iotdb-thrift-sink',
325-
'node-urls' = '127.0.0.1:6667' -- URL of the DataNode service port on the target IoTDB
326-
)
327-
```
328-
329-
### 3.4 Edge-to-Cloud Data Transmission
295+
### 3.3 Edge-to-Cloud Data Transmission
330296

331297
This example demonstrates synchronizing data from multiple IoTDB clusters (B, C, D) to a central IoTDB cluster (A). The data pipeline is shown below:
332298

@@ -376,14 +342,13 @@ WITH SINK (
376342
)
377343
```
378344

379-
### 3.5 Cascaded Data Transmission
345+
### 3.4 Cascaded Data Transmission
380346

381347
This example demonstrates cascading data transmission from IoTDB A to IoTDB B and then to IoTDB C. The data pipeline is shown below:
382348

383349
![](/img/sync_en_04.png)
384350

385-
To synchronize data from cluster A to cluster C, the `source.mode.double-living` parameter is set to `true` in the pipe between B and C.
386-
351+
387352
SQL Example: On IoTDB A:
388353

389354
```SQL
@@ -407,7 +372,7 @@ WITH SINK (
407372
```
408373

409374

410-
### 3.6 Compressed Synchronization
375+
### 3.5 Compressed Synchronization
411376

412377
IoTDB supports specifying data compression methods during synchronization. The `compressor` parameter can be configured to enable real-time data compression and transmission. Supported algorithms include `snappy`, `gzip`, `lz4`, `zstd`, and `lzma2`. Multiple algorithms can be combined and applied in the configured order. The `rate-limit-bytes-per-second` parameter (supported in V1.3.3 and later) limits the maximum number of bytes transmitted per second (calculated after compression). If set to a value less than 0, there is no limit.
413378

@@ -423,7 +388,7 @@ WITH SINK (
423388
```
424389

425390

426-
### 3.7 Encrypted Synchronization
391+
### 3.6 Encrypted Synchronization
427392

428393
IoTDB supports SSL encryption during synchronization to securely transmit data between IoTDB instances. By configuring SSL-related parameters such as the certificate path (`ssl.trust-store-path`) and password (`ssl.trust-store-pwd`), data can be protected by SSL encryption during synchronization.
429394

@@ -519,7 +484,6 @@ pipe_all_sinks_rate_limit_bytes_per_second=-1
519484
| table-name | When the user connects with `sql_dialect` set to `table`, this parameter can be specified. Determines the scope of data capture, affecting the `data` in `inclusion`. Specifies the table name to filter. It can be a specific table name or a Java-style regular expression to match multiple tables. By default, all tables are matched. | String: Data table name or data table regular expression pattern string, which can be uncreated or non - existent tables. | No | ".*" |
520485
| start-time | Determines the scope of data capture, affecting the `data` in `inclusion`. Data with an event time **greater than or equal to** this parameter will be selected for stream processing in the pipe. | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp)orString: ISO format timestamp supported by IoTDB | No | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp) |
521486
| end-time | Determines the scope of data capture, affecting the `data` in `inclusion`. Data with an event time **less than or equal to** this parameter will be selected for stream processing in the pipe. | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp)orString: ISO format timestamp supported by IoTDB | No | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp) |
522-
| mode.double-living | Whether to enable full dual-active mode. When enabled, the system will ignore the `-sql_dialect` connection method to capture all tree-table model data and not forward data synced from another pipe (to avoid circular synchronization). | Boolean: true / false | No | false |
523487

524488
> 💎 **Note:** The difference between the values of true and false for the data extraction mode `mode.streaming`
525489
>

‎src/UserGuide/Master/Table/User-Manual/Data-Sync_timecho.md‎

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -393,8 +393,7 @@ This example demonstrates cascading data transmission from IoTDB A to IoTDB B an
393393

394394
![](/img/sync_en_04.png)
395395

396-
To synchronize data from cluster A to cluster C, the `source.mode.double-living` parameter is set to `true` in the pipe between B and C.
397-
396+
398397
SQL Example: On IoTDB A:
399398

400399
```SQL

‎src/UserGuide/latest-Table/User-Manual/Data-Sync_apache.md‎

Lines changed: 4 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -292,41 +292,7 @@ WITH SINK (
292292
'node-urls' = '127.0.0.1:6668' -- The URL of the DataNode's data service port in the target IoTDB instance.
293293
)
294294
```
295-
### 3.3 Bidirectional Data Transmission
296-
297-
This example demonstrates a scenario where two IoTDB instances act as dual-active systems. The data pipeline is shown below:
298-
299-
![](/img/e3.png)
300-
301-
To avoid infinite data loops, the `source.mode.double-living` parameter must be set to `true` on both IoTDB A and B, indicating that data forwarded from another pipe will not be retransmitted.
302-
303-
SQL Example: On IoTDB A:
304-
305-
```SQL
306-
CREATE PIPE AB
307-
WITH SOURCE (
308-
'source.mode.double-living' = 'true' -- Do not forward data from other pipes
309-
)
310-
WITH SINK (
311-
'sink' = 'iotdb-thrift-sink',
312-
'node-urls' = '127.0.0.1:6668' -- URL of the DataNode service port on the target IoTDB
313-
)
314-
```
315-
316-
On IoTDB B:
317-
318-
```SQL
319-
CREATE PIPE BA
320-
WITH SOURCE (
321-
'source.mode.double-living' = 'true' -- Do not forward data from other pipes
322-
)
323-
WITH SINK (
324-
'sink' = 'iotdb-thrift-sink',
325-
'node-urls' = '127.0.0.1:6667' -- URL of the DataNode service port on the target IoTDB
326-
)
327-
```
328-
329-
### 3.4 Edge-to-Cloud Data Transmission
295+
### 3.3 Edge-to-Cloud Data Transmission
330296

331297
This example demonstrates synchronizing data from multiple IoTDB clusters (B, C, D) to a central IoTDB cluster (A). The data pipeline is shown below:
332298

@@ -376,13 +342,12 @@ WITH SINK (
376342
)
377343
```
378344

379-
### 3.5 Cascaded Data Transmission
345+
### 3.4 Cascaded Data Transmission
380346

381347
This example demonstrates cascading data transmission from IoTDB A to IoTDB B and then to IoTDB C. The data pipeline is shown below:
382348

383349
![](/img/sync_en_04.png)
384350

385-
To synchronize data from cluster A to cluster C, the `source.mode.double-living` parameter is set to `true` in the pipe between B and C.
386351

387352
SQL Example: On IoTDB A:
388353

@@ -407,7 +372,7 @@ WITH SINK (
407372
```
408373

409374

410-
### 3.6 Compressed Synchronization
375+
### 3.5 Compressed Synchronization
411376

412377
IoTDB supports specifying data compression methods during synchronization. The `compressor` parameter can be configured to enable real-time data compression and transmission. Supported algorithms include `snappy`, `gzip`, `lz4`, `zstd`, and `lzma2`. Multiple algorithms can be combined and applied in the configured order. The `rate-limit-bytes-per-second` parameter (supported in V1.3.3 and later) limits the maximum number of bytes transmitted per second (calculated after compression). If set to a value less than 0, there is no limit.
413378

@@ -423,7 +388,7 @@ WITH SINK (
423388
```
424389

425390

426-
### 3.7 Encrypted Synchronization
391+
### 3.6 Encrypted Synchronization
427392

428393
IoTDB supports SSL encryption during synchronization to securely transmit data between IoTDB instances. By configuring SSL-related parameters such as the certificate path (`ssl.trust-store-path`) and password (`ssl.trust-store-pwd`), data can be protected by SSL encryption during synchronization.
429394

@@ -519,7 +484,6 @@ pipe_all_sinks_rate_limit_bytes_per_second=-1
519484
| table-name | When the user connects with `sql_dialect` set to `table`, this parameter can be specified. Determines the scope of data capture, affecting the `data` in `inclusion`. Specifies the table name to filter. It can be a specific table name or a Java-style regular expression to match multiple tables. By default, all tables are matched. | String: Data table name or data table regular expression pattern string, which can be uncreated or non - existent tables. | No | ".*" |
520485
| start-time | Determines the scope of data capture, affecting the `data` in `inclusion`. Data with an event time **greater than or equal to** this parameter will be selected for stream processing in the pipe. | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp)orString: ISO format timestamp supported by IoTDB | No | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp) |
521486
| end-time | Determines the scope of data capture, affecting the `data` in `inclusion`. Data with an event time **less than or equal to** this parameter will be selected for stream processing in the pipe. | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp)orString: ISO format timestamp supported by IoTDB | No | Long: [Long.MIN_VALUE, Long.MAX_VALUE](Unix bare timestamp) |
522-
| mode.double-living | Whether to enable full dual-active mode. When enabled, the system will ignore the `-sql_dialect` connection method to capture all tree-table model data and not forward data synced from another pipe (to avoid circular synchronization). | Boolean: true / false | No | false |
523487

524488
> 💎 **Note:** The difference between the values of true and false for the data extraction mode `mode.streaming`
525489
>

‎src/UserGuide/latest-Table/User-Manual/Data-Sync_timecho.md‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -393,7 +393,6 @@ This example demonstrates cascading data transmission from IoTDB A to IoTDB B an
393393

394394
![](/img/sync_en_04.png)
395395

396-
To synchronize data from cluster A to cluster C, the `source.mode.double-living` parameter is set to `true` in the pipe between B and C.
397396

398397
SQL Example: On IoTDB A:
399398

0 commit comments

Comments
 (0)