Merge branch 'main' into merge/mainto3.0
This commit is contained in:
Shengliang Guan
commit
41435233a2
|
|
@ -9,13 +9,12 @@ Apache Superset provides an intuitive user interface that makes creating, sharin
|
|||
|
||||
Through the Python connector of TDengine, Superset can support TDengine data sources and provide functions such as data presentation and analysis
|
||||
|
||||
## Install Apache Superset
|
||||
## Prerequisites
|
||||
|
||||
Ensure that Apache Superset v2.1.0 or above is installed. If not, please visit [official website](https://superset.apache.org/) to install
|
||||
|
||||
## Install TDengine
|
||||
|
||||
Both TDengine Enterprise Edition and Community Edition are supported, with version requirements of 3.0 or higher
|
||||
Prepare the following environment:
|
||||
- TDengine is installed and running normally (both Enterprise and Community versions are available)
|
||||
- taosAdapter is running normally, refer to [taosAdapter](../../../reference/components/taosAdapter)
|
||||
- Apache Superset version 2.1.0 or above is already installed, refre to [Apache Superset](https://superset.apache.org/)
|
||||
|
||||
## Install TDengine Python Connector
|
||||
|
||||
|
|
|
|||
|
|
@ -4,22 +4,17 @@ sidebar_label: taosdump
|
|||
slug: /tdengine-reference/tools/taosdump
|
||||
---
|
||||
|
||||
taosdump is a tool application that supports backing up data from a running TDengine cluster and restoring the backed-up data to the same or another running TDengine cluster.
|
||||
|
||||
taosdump can back up data using databases, supertables, or basic tables as logical data units, and can also back up data records within a specified time period from databases, supertables, and basic tables. You can specify the directory path for data backup; if not specified, taosdump defaults to backing up data to the current directory.
|
||||
|
||||
If the specified location already has data files, taosdump will prompt the user and exit immediately to avoid data being overwritten. This means the same path can only be used for one backup.
|
||||
If you see related prompts, please operate carefully.
|
||||
|
||||
taosdump is a logical backup tool, it should not be used to back up any raw data, environment settings, hardware information, server configuration, or cluster topology. taosdump uses [Apache AVRO](https://avro.apache.org/) as the data file format to store backup data.
|
||||
`taosdump` is a TDengine data backup/recovery tool provided for open source users, and the backed up data files adopt the standard [Apache AVRO](https://avro.apache.org/)
|
||||
Format, convenient for exchanging data with the external ecosystem.
|
||||
Taosdump provides multiple data backup and recovery options to meet different data needs, and all supported options can be viewed through --help.
|
||||
|
||||
## Installation
|
||||
|
||||
There are two ways to install taosdump:
|
||||
Taosdump provides two installation methods:
|
||||
|
||||
- Install the official taosTools package, please find taosTools on the [release history page](../../../release-history/taostools/) and download it for installation.
|
||||
- Taosdump is the default installation component in the TDengine installation package, which can be used after installing TDengine. For how to install TDengine, please refer to [TDengine Installation](../../../get-started/)
|
||||
|
||||
- Compile taos-tools separately and install, please refer to the [taos-tools](https://github.com/taosdata/taos-tools) repository for details.
|
||||
- Compile and install taos tools separately, refer to [taos tools](https://github.com/taosdata/taos-tools) .
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
|
|
@ -30,6 +25,9 @@ There are two ways to install taosdump:
|
|||
3. Backup certain supertables or basic tables in a specified database: use the `dbname stbname1 stbname2 tbname1 tbname2 ...` parameter, note that this input sequence starts with the database name, supports only one database, and the second and subsequent parameters are the names of the supertables or basic tables in that database, separated by spaces;
|
||||
4. Backup the system log database: TDengine clusters usually include a system database named `log`, which contains data for TDengine's own operation, taosdump does not back up the log database by default. If there is a specific need to back up the log database, you can use the `-a` or `--allow-sys` command line parameter.
|
||||
5. "Tolerant" mode backup: Versions after taosdump 1.4.1 provide the `-n` and `-L` parameters, used for backing up data without using escape characters and in "tolerant" mode, which can reduce backup data time and space occupied when table names, column names, and label names do not use escape characters. If unsure whether to use `-n` and `-L`, use the default parameters for "strict" mode backup. For an explanation of escape characters, please refer to the [official documentation](../../sql-manual/escape-characters/).
|
||||
6. If a backup file already exists in the directory specified by the `-o` parameter, to prevent data from being overwritten, taosdump will report an error and exit. Please replace it with another empty directory or clear the original data before backing up.
|
||||
7. Currently, taosdump does not support data breakpoint backup function. Once the data backup is interrupted, it needs to be started from scratch.
|
||||
If the backup takes a long time, it is recommended to use the (-S -E options) method to specify the start/end time for segmented backup.
|
||||
|
||||
:::tip
|
||||
|
||||
|
|
@ -42,7 +40,8 @@ There are two ways to install taosdump:
|
|||
|
||||
### taosdump Restore Data
|
||||
|
||||
Restore data files from a specified path: use the `-i` parameter along with the data file path. As mentioned earlier, the same directory should not be used to back up different data sets, nor should the same path be used to back up the same data set multiple times, otherwise, the backup data will cause overwriting or multiple backups.
|
||||
- Restore data files from a specified path: use the `-i` parameter along with the data file path. As mentioned earlier, the same directory should not be used to back up different data sets, nor should the same path be used to back up the same data set multiple times, otherwise, the backup data will cause overwriting or multiple backups.
|
||||
- taosdump supports data recovery to a new database name with the parameter `-W`, please refer to the command line parameter description for details.
|
||||
|
||||
:::tip
|
||||
taosdump internally uses the TDengine stmt binding API to write restored data, currently using 16384 as a batch for writing. If there are many columns in the backup data, it may cause a "WAL size exceeds limit" error, in which case you can try adjusting the `-B` parameter to a smaller value.
|
||||
|
|
@ -105,6 +104,13 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
the table name.(Version 2.5.3)
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is
|
||||
8.
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
-k, --retry-count=VALUE Set the number of retry attempts for connection or
|
||||
query failures
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service
|
||||
-R, --restful Use RESTful interface to connect TDengine
|
||||
-t, --timeout=SECONDS The timeout seconds for websocket to interact.
|
||||
|
|
@ -112,10 +118,6 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
-?, --help Give this help list
|
||||
--usage Give a short usage message
|
||||
-V, --version Print program version
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
|
||||
Mandatory or optional arguments to long options are also mandatory or optional
|
||||
for any corresponding short options.
|
||||
|
|
|
|||
|
|
@ -4,35 +4,38 @@ sidebar_label: taosBenchmark
|
|||
slug: /tdengine-reference/tools/taosbenchmark
|
||||
---
|
||||
|
||||
taosBenchmark (formerly known as taosdemo) is a tool for testing the performance of the TDengine product. taosBenchmark can test the performance of TDengine's insert, query, and subscription functions. It can simulate massive data generated by a large number of devices and flexibly control the number of databases, supertables, types and number of tag columns, types and number of data columns, number of subtables, data volume per subtable, data insertion interval, number of working threads in taosBenchmark, whether and how to insert out-of-order data, etc. To accommodate the usage habits of past users, the installation package provides taosdemo as a soft link to taosBenchmark.
|
||||
TaosBenchmark is a performance benchmarking tool for TDengine products, providing insertion, query, and subscription performance testing for TDengine products, and outputting performance indicators.
|
||||
|
||||
## Installation
|
||||
|
||||
There are two ways to install taosBenchmark:
|
||||
taosBenchmark provides two installation methods:
|
||||
|
||||
- taosBenchmark is automatically installed with the official TDengine installation package, for details please refer to [TDengine Installation](../../../get-started/).
|
||||
- taosBenchmark is the default installation component in the TDengine installation package, which can be used after installing TDengine. For how to install TDengine, please refer to [TDengine Installation](../../../get started/)
|
||||
|
||||
- Compile and install taos-tools separately, for details please refer to the [taos-tools](https://github.com/taosdata/taos-tools) repository.
|
||||
- Compile and install taos tools separately, refer to [taos tools](https://github.com/taosdata/taos-tools) .
|
||||
|
||||
## Operation
|
||||
|
||||
### Configuration and Operation Methods
|
||||
|
||||
taosBenchmark needs to be executed in the operating system's terminal, and this tool supports two configuration methods: Command Line Arguments and JSON Configuration File. These two methods are mutually exclusive; when using a configuration file, only one command line argument `-f <json file>` can be used to specify the configuration file. When using command line arguments to run taosBenchmark and control its behavior, the `-f` parameter cannot be used; instead, other parameters must be used for configuration. In addition, taosBenchmark also offers a special mode of operation, which is running without any parameters.
|
||||
|
||||
taosBenchmark supports comprehensive performance testing for TDengine, and the TDengine features it supports are divided into three categories: writing, querying, and subscribing. These three functions are mutually exclusive, and each run of taosBenchmark can only select one of them. It is important to note that the type of function to be tested is not configurable when using the command line configuration method; the command line configuration method can only test writing performance. To test TDengine's query and subscription performance, you must use the configuration file method and specify the type of function to be tested through the `filetype` parameter in the configuration file.
|
||||
taosBbenchmark supports three operating modes:
|
||||
- No parameter mode
|
||||
- Command line mode
|
||||
- JSON configuration file mode
|
||||
The command-line approach is a subset of the functionality of JSON configuration files, which immediately uses the command line and then the configuration file, with the parameters specified by the command line taking precedence.
|
||||
|
||||
**Ensure that the TDengine cluster is running correctly before running taosBenchmark.**
|
||||
|
||||
### Running Without Command Line Arguments
|
||||
|
||||
Execute the following command to quickly experience taosBenchmark performing a write performance test on TDengine based on the default configuration.
|
||||
|
||||
Execute the following command to quickly experience taosBenchmark performing a write performance test on TDengine based on the default configuration.
|
||||
```shell
|
||||
taosBenchmark
|
||||
```
|
||||
|
||||
When running without parameters, taosBenchmark by default connects to the TDengine cluster specified under `/etc/taos`, and creates a database named `test` in TDengine, under which a supertable named `meters` is created, and 10,000 tables are created under the supertable, each table having 10,000 records inserted. Note that if a `test` database already exists, this command will delete the existing database and create a new `test` database.
|
||||
When running without parameters, taosBenchmark defaults to connecting to the TDengine cluster specified in `/etc/taos/taos.cfg `.
|
||||
After successful connection, a smart meter example database test, super meters, and 10000 sub meters will be created, with 10000 records per sub meter. If the test database already exists, it will be deleted before creating a new one.
|
||||
|
||||
### Running Using Command Line Configuration Parameters
|
||||
|
||||
|
|
@ -46,9 +49,7 @@ The above command `taosBenchmark` will create a database named `test`, establish
|
|||
|
||||
### Running Using a Configuration File
|
||||
|
||||
The taosBenchmark installation package includes examples of configuration files, located in `<install_directory>/examples/taosbenchmark-json`
|
||||
|
||||
Use the following command line to run taosBenchmark and control its behavior through a configuration file.
|
||||
Running in configuration file mode provides all functions, so parameters can be configured to run in the configuration file.
|
||||
|
||||
```shell
|
||||
taosBenchmark -f <json file>
|
||||
|
|
@ -214,6 +215,61 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
- **-?/--help**:
|
||||
Displays help information and exits. Cannot be used with other parameters.
|
||||
|
||||
|
||||
## Output performance indicators
|
||||
|
||||
#### Write indicators
|
||||
|
||||
After writing is completed, a summary performance metric will be output in the last two lines in the following format:
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
First line write speed statistics:
|
||||
- Spent: Total write time, in seconds, counting from the start of writing the first data to the end of the last data. This indicates that a total of 8.527298 seconds were spent
|
||||
- Real: Total write time (calling the engine), excluding the time spent preparing data for the testing framework. Purely counting the time spent on engine calls, The time spent is 8.117379 seconds. If 8.527298-8.117379=0.409919 seconds, it is the time spent preparing data for the testing framework
|
||||
- Rows: Write the total number of rows, which is 10 million pieces of data
|
||||
- Threads: The number of threads being written, which is 8 threads writing simultaneously
|
||||
- Records/second write speed = `total write time` / `total number of rows written`, real in parentheses is the same as before, indicating pure engine write speed
|
||||
|
||||
Second line single write delay statistics:
|
||||
- min: Write minimum delay
|
||||
- avg: Write normal delay
|
||||
- p90: Write delay p90 percentile delay number
|
||||
- p95: Write delay p95 percentile delay number
|
||||
- p99: Write delay p99 percentile delay number
|
||||
- max: maximum write delay
|
||||
Through this series of indicators, the distribution of write request latency can be observed
|
||||
|
||||
#### Query indicators
|
||||
The query performance test mainly outputs the QPS indicator of query request speed, and the output format is as follows:
|
||||
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Total specified queries: 30000
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
|
||||
- The first line represents the percentile distribution of query execution and query request delay for each of the three threads executing 10000 queries. The SQL command is the test query statement
|
||||
- The second line indicates that a total of 10000 * 3 = 30000 queries have been completed
|
||||
- The third line indicates that the total query time is 26.9653 seconds, and the query rate per second (QPS) is 1113.049 times/second
|
||||
|
||||
#### Subscription metrics
|
||||
|
||||
The subscription performance test mainly outputs consumer consumption speed indicators, with the following output format:
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
- Lines 1 to 3 real-time output of the current consumption speed of each consumer, msgs/s represents the number of consumption messages, each message contains multiple rows of data, and rows/s represents the consumption speed calculated by rows
|
||||
- Lines 4 to 6 show the overall statistics of each consumer after the test is completed, including the total number of messages consumed and the total number of lines
|
||||
- The overall statistics of all consumers in line 7, `msgs` represents how many messages were consumed in total, `rows` represents how many rows of data were consumed in total
|
||||
|
||||
## Configuration File Parameters Detailed Explanation
|
||||
|
||||
### General Configuration Parameters
|
||||
|
|
@ -331,21 +387,6 @@ Parameters related to supertable creation are configured in the `super_tables` s
|
|||
- **repeat_ts_max** : Numeric type, when composite primary key is enabled, specifies the maximum number of records with the same timestamp to be generated
|
||||
- **sqls** : Array of strings type, specifies the array of sql to be executed after the supertable is successfully created, the table name specified in sql must be prefixed with the database name, otherwise an unspecified database error will occur
|
||||
|
||||
#### tsma Configuration Parameters
|
||||
|
||||
Specify the configuration parameters for tsma in `super_tables` under `tsmas`, with the following specific parameters:
|
||||
|
||||
- **name**: Specifies the name of the tsma, mandatory.
|
||||
|
||||
- **function**: Specifies the function of the tsma, mandatory.
|
||||
|
||||
- **interval**: Specifies the time interval for the tsma, mandatory.
|
||||
|
||||
- **sliding**: Specifies the window time shift for the tsma, mandatory.
|
||||
|
||||
- **custom**: Specifies custom configuration appended at the end of the tsma creation statement, optional.
|
||||
|
||||
- **start_when_inserted**: Specifies when to create the tsma after how many rows are inserted, optional, default is 0.
|
||||
|
||||
#### Tag and Data Column Configuration Parameters
|
||||
|
||||
|
|
@ -423,6 +464,11 @@ For other common parameters, see Common Configuration Parameters.
|
|||
|
||||
Configuration parameters for querying specified tables (can specify supertables, subtables, or regular tables) are set in `specified_table_query`.
|
||||
|
||||
- **mixed_query** "yes": `Mixed Query` "no": `Normal Query`, default is "no"
|
||||
`Mixed Query`: All SQL statements in `sqls` are grouped by the number of threads, with each thread executing one group. Each SQL statement in a thread needs to perform `query_times` queries.
|
||||
`Normal Query `: Each SQL in `sqls` starts `threads` and exits after executing `query_times` times. The next SQL can only be executed after all previous SQL threads have finished executing and exited.
|
||||
Regardless of whether it is a `Normal Query` or `Mixed Query`, the total number of query executions is the same. The total number of queries = `sqls` * `threads` * `query_times`. The difference is that `Normal Query` starts `threads` for each SQL query, while ` Mixed Query` only starts `threads` once to complete all SQL queries. The number of thread startups for the two is different.
|
||||
|
||||
- **query_interval** : Query interval, in seconds, default is 0.
|
||||
|
||||
- **threads** : Number of threads executing the SQL query, default is 1.
|
||||
|
|
@ -434,6 +480,7 @@ Configuration parameters for querying specified tables (can specify supertables,
|
|||
#### Configuration Parameters for Querying Supertables
|
||||
|
||||
Configuration parameters for querying supertables are set in `super_table_query`.
|
||||
The thread mode of the super table query is the same as the `Normal Query` mode of the specified query statement described above, except that `sqls` is filled all sub tables.
|
||||
|
||||
- **stblname** : The name of the supertable to query, required.
|
||||
|
||||
|
|
|
|||
|
|
@ -328,8 +328,35 @@ In addition to precomputation, TDengine also supports various downsampling stora
|
|||
|
||||
### Multi-Level Storage and Object Storage
|
||||
|
||||
By default, TDengine stores all data in the /var/lib/taos directory. To expand storage capacity, reduce potential bottlenecks caused by file reading, and enhance data throughput, TDengine allows the use of the configuration parameter `dataDir` to enable the cluster to utilize multiple mounted hard drives simultaneously.
|
||||
By default, TDengine saves all data in /var/lib/taos directory, and the data files of each vnode are saved in a different directory under this directory. In order to expand the storage space, minimize the bottleneck of file reading and improve the data throughput rate, TDengine can configure the system parameter "dataDir" to allow multiple mounted hard disks to be used by system at the same time. In addition, TDengine also provides the function of tiered data storage, i.e. storage on different storage media according to the time stamps of data files. For example, the latest data is stored on SSD, the data older than a week is stored on local hard disk, and data older than four weeks is stored on network storage device. This reduces storage costs and ensures efficient data access. The movement of data on different storage media is automatically done by the system and is completely transparent to applications. Tiered storage of data is also configured through the system parameter "dataDir".
|
||||
|
||||
dataDir format is as follows:
|
||||
|
||||
```
|
||||
dataDir data_path [tier_level] [primary] [disable_create_new_file]
|
||||
```
|
||||
|
||||
Where `data_path` is the folder path of mount point, and `tier_level` is the media storage-tier. The higher the media storage-tier, means the older the data file. Multiple hard disks can be mounted at the same storage-tier, and data files on the same storage-tier are distributed on all hard disks within the tier. TDengine supports up to 3 tiers of storage, so tier_level values are 0, 1, and 2. When configuring dataDir, there must be only one mount path without specifying tier_level, which is called special mount disk (path). The mount path defaults to level 0 storage media and contains special file links, which cannot be removed, otherwise it will have a devastating impact on the written data. And `primary` means whether the data dir is the primary mount point. Enter 0 for false or 1 for true. The default value is 1. A TDengine cluster can have only one `primary` mount point, which must be on tier 0. And `disable_create_new_file` means whether to prohibit the creation of new file sets on the specified mount point. Enter 0 for false and 1 for true. The default value is 0. Tier 0 storage must have at least one mount point with disable_create_new_file set to 0. Tier 1 and tier 2 storage do not have this restriction.
|
||||
|
||||
Suppose there is a physical node with six mountable hard disks/mnt/disk1,/mnt/disk2, ..., /mnt/disk6, where disk1 and disk2 need to be designated as level 0 storage media, disk3 and disk4 are level 1 storage media, and disk5 and disk6 are level 2 storage media. Disk1 is a special mount disk, you can configure it in/etc/taos/taos.cfg as follows:
|
||||
|
||||
```
|
||||
dataDir /mnt/disk1/taos 0 1 0
|
||||
dataDir /mnt/disk2/taos 0 0 0
|
||||
dataDir /mnt/disk3/taos 1 0 0
|
||||
dataDir /mnt/disk4/taos 1 0 1
|
||||
dataDir /mnt/disk5/taos 2 0 0
|
||||
dataDir /mnt/disk6/taos 2 0 0
|
||||
```
|
||||
|
||||
Mounted disks can also be a non-local network disk, as long as the system can access it.
|
||||
|
||||
You can use the following command to dynamically modify dataDir to control whether disable_create_new_file is enabled for the current directory.
|
||||
|
||||
```
|
||||
alter dnode 1 "/mnt/disk2/taos 1";
|
||||
```
|
||||
|
||||
Note: Tiered Storage is only supported in Enterprise Edition
|
||||
|
||||
Additionally, TDengine offers tiered data storage functionality, allowing users to store data from different time periods in directories on different storage devices. This facilitates the separation of "hot" data (frequently accessed) and "cold" data (less frequently accessed), making full use of various storage resources while saving costs. For example, data that is recently collected and requires frequent access can be stored on high-performance solid-state drives due to their high read performance requirements. Data that exceeds a certain age and has lower query demands can be stored on mechanically driven hard disks, which are relatively cheaper.
|
||||
|
||||
To further reduce storage costs, TDengine also supports storing time-series data in object storage systems. Through its innovative design, in most cases, the performance of querying time-series data from object storage systems is close to half that of local disks, and in some scenarios, the performance can even be comparable to local disks. Additionally, TDengine allows users to perform delete and update operations on time-series data stored in object storage.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ pidfile = /usr/local/taos/taosanode/taosanode.pid
|
|||
# uWSGI log files
|
||||
logto = /var/log/taos/taosanode/taosanode.log
|
||||
|
||||
# wWSGI monitor port
|
||||
# uWSGI monitor port
|
||||
stats = 127.0.0.1:8387
|
||||
|
||||
# python virtual environment directory, used by Anode
|
||||
|
|
@ -86,7 +86,7 @@ log-level = DEBUG
|
|||
|
||||
**提示**
|
||||
请勿设置 `daemonize` 参数，该参数会导致 uWSGI 与 systemctl 冲突，从而导致 Anode 无法正常启动。
|
||||
上面的示例配置文件 `taosanode.ini` 只包含了使用 Anode 提供服务的基础配置参数，对于 uWSGI 的其他配置参数的设置及其说明请参考 [uWSGIS官方文档](https://uwsgi-docs-zh.readthedocs.io/zh-cn/latest/Options.html)。
|
||||
上面的示例配置文件 `taosanode.ini` 只包含了使用 Anode 提供服务的基础配置参数，对于 uWSGI 的其他配置参数的设置及其说明请参考 [uWSGI 官方文档](https://uwsgi-docs-zh.readthedocs.io/zh-cn/latest/Options.html)。
|
||||
|
||||
Anode 运行配置主要是以下：
|
||||
- app-log: Anode 服务运行产生的日志，用户可以调整其到需要的位置
|
||||
|
|
@ -110,7 +110,7 @@ SHOW ANODES;
|
|||
taos> show anodes;
|
||||
id | url | status | create_time | update_time |
|
||||
==================================================================================================================
|
||||
1 | 192.168.0.1:6090 | ready | 2024-11-28 18:44:27.089 | 2024-11-28 18:44:27.089 |
|
||||
1 | 192.168.0.1:6090 | ready | 2024-11-28 18:44:27.089 | 2024-11-28 18:44:27.089 |
|
||||
Query OK, 1 row(s) in set (0.037205s)
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ algo=expr1
|
|||
"}
|
||||
|
||||
```
|
||||
1. `column_expr`：预测的时序数据列。与异常检测相同，只支持数值类型列输入。
|
||||
1. `column_expr`：预测的时序数据列，只支持数值类型列输入。
|
||||
2. `options`：预测函数的参数。字符串类型，其中使用 K=V 方式调用算法及相关参数。采用逗号分隔的 K=V 字符串表示，其中的字符串不需要使用单引号、双引号、或转义号等符号，不能使用中文及其他宽字符。预测支持 `conf`, `every`, `rows`, `start`, `rows` 几个控制参数，其含义如下：
|
||||
|
||||
### 参数说明
|
||||
|
|
|
|||
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
title: 三副本方案
|
||||
sidebar_label: 三副本方案
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包括元数据和时序数据。一个虚拟节点组（VGroup）构成了一个 RAFT 组；VGroup 中的虚拟节点（Vnode），便是该 RAFT 组的成员节点，也称之为副本。
|
||||
|
||||
1. 每个 Vnode 都有自己的角色，可以是 Leader（领导者）、Follower（跟随者）、Candidate（候选人）。
|
||||
2. 每个 Vnode 都维护了一份连续的日志，用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目组成，每条日志都有唯一的编号，用于标识日志协商或执行的进度。
|
||||
3. Leader 角色的 Vnode 提供读写服务，在故障节点不超过半数的情况下保证集群的高可用性。此外，即使发生了节点重启及 Leader 重新选举等事件后，RAFT 协议也能够始终保证新产生的 Leader 可以提供已经写入成功的全部完整数据的读写服务。
|
||||
4. 每一次对数据库的变更请求（比如数据写入），都对应一条日志。在持续写入数据的过程中，会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 文件的形式存储在数据文件目录中。
|
||||
5. 只有当过半数的节点把该条日志追加到 WAL 文件，并且收到确认消息之后，这条日志才会被 Leader 认为是安全的；此时该日志进入 committed 状态，完成数据的插入，随后该日志被标记为 applied 的状态。
|
||||
|
||||
多副本工作原理参见 [数据写入与复制流程](../../26-tdinternal/01-arch.md#数据写入与复制流程)
|
||||
|
||||
## 集群配置
|
||||
|
||||
三副本要求集群至少配置三个服务器节点，基本部署与配置步骤如下：
|
||||
1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts
|
||||
2. 各节点分别安装 TDengine 服务端安装包，按需编辑好各节点 taos.cfg
|
||||
3. 启动各节点 taosd 服务，其他服务可按需启动（taosadapter/taosx/taoskeeper/taos-explorer)
|
||||
|
||||
## 运维命令
|
||||
|
||||
### 创建集群
|
||||
|
||||
创建三节点的集群
|
||||
|
||||
```sql
|
||||
CREATE dnode <dnode_ep> port <dnode_port>;
|
||||
CREATE dnode <dnode_ep> port <dnode_port>;
|
||||
```
|
||||
|
||||
创建三副本的 Mnode，保证 Mnode 高可用
|
||||
|
||||
```sql
|
||||
CREATE mnode on dnode <dnode_id>;
|
||||
CREATE mnode on dnode <dnode_id>;
|
||||
```
|
||||
|
||||
### 数据库创建
|
||||
|
||||
创建三副本的数据库
|
||||
|
||||
```sql
|
||||
create database <dbname> replica 3 vgroups xx buffer xx ...
|
||||
```
|
||||
|
||||
### 修改数据库副本数
|
||||
|
||||
创建了单副本数据库后，如果希望改为三副本时，可通过 alter 命令来实现，反之亦然
|
||||
|
||||
```sql
|
||||
alter database <dbname> replica 3|1
|
||||
```
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 1. 创建三副本数据库或修改为三副本时，报错：DB error: Out of dnodes
|
||||
- 服务器节点数不足：原因是服务器节点数少于三个。
|
||||
- 解决方案：增加服务器节点数量，满足最低要求。
|
||||
|
||||
### 2. 创建三副本数据库或 split vgroup 时，报错：DB error: Vnodes exhausted
|
||||
- 服务器可用 Vnodes 不足：原因是某些服务器节点可用 Vnodes 数少于建库或 split vgroup 的需求数。
|
||||
- 解决方案：调整服务器 CPU 数量、SupportVnodes 配置参数，满足建库要求。
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
title: 双副本方案
|
||||
sidebar_label: 双副本方案
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
部分用户期望在保证一定可靠性、可用性条件下，尽可能压缩部署成本。为此，TDengine 提出基于 Arbitrator 的双副本方案，可提供集群中**只有单个服务故障且不出现连续故障**的容错能力。双副本方案是 TDengine Enterprise 特有功能，在 3.3.0.0 版本中第一次发布，建议使用最新版本。
|
||||
|
||||
双副本选主由高可用的 Mnode 提供仲裁服务，不由 Raft 组内决定。
|
||||
1. Arbitrator：仲裁服务，不存储数据，VGroup 因某一 Vnode 故障而无法提供服务时，Arbitrator 可根据数据同步情况指定 VGroup 内另一 Vnode 成为 Assigned Leader
|
||||
2. AssignedLeader：被强制设置为 Leader 的 Vnode，无论其他副本 Vnode 是否存活，均可一直响应用户请求
|
||||
|
||||
|
||||
|
||||
## 集群配置
|
||||
|
||||
双副本要求集群至少配置三个节点，基本部署与配置步骤如下：
|
||||
1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts
|
||||
2. 各节点分别安装 TDengine **企业版**服务端安装包，按需编辑好各节点 taos.cfg
|
||||
3. 可选择其中一个节点仅提供仲裁服务（部署 Mnode），将 SupportVnodes 参数设置为 0，表示不存储时序数据；该占用资源较少，仅需 1~2 核，且可与其他应用共用
|
||||
4. 启动各节点 taosd 服务，其他服务可按需启动（taosadapter/taosx/taoskeeper/taos-explorer)
|
||||
|
||||
## 约束条件
|
||||
1. 最小配置的服务器节点数为 2+1 个，其中两个数据节点，一个仲裁节点
|
||||
2. 双副本为数据库建库参数，不同数据库可按需选择副本数
|
||||
3. 支持 TDengine 集群的完整特性，包括：读缓存、数据订阅、流计算等
|
||||
4. 支持 TDengine 所有语言连接器以及连接方式
|
||||
5. 支持单副本与双副本之间切换（前提是节点数量满足需求、各节点可用 Vnode 数量/内存/存储空间足够）
|
||||
6. 不支持双副本与三副本之间的切换
|
||||
7. 不支持双副本切换为双活，除非另外部署一套实例与当前实例组成双活方案
|
||||
|
||||
## 运维命令
|
||||
|
||||
### 创建集群
|
||||
|
||||
创建三节点的集群
|
||||
|
||||
```sql
|
||||
CREATE dnode <dnode_ep> port <dnode_port>;
|
||||
CREATE dnode <dnode_ep> port <dnode_port>;
|
||||
```
|
||||
|
||||
创建三副本的 Mnode，保证 Mnode 高可用，确保仲裁服务的高可用
|
||||
|
||||
```sql
|
||||
CREATE mnode on dnode <dnode_id>;
|
||||
CREATE mnode on dnode <dnode_id>;
|
||||
```
|
||||
|
||||
### 数据库创建
|
||||
|
||||
按需创建双副本数据库
|
||||
|
||||
```sql
|
||||
create database <dbname> replica 2 vgroups xx buffer xx ...
|
||||
```
|
||||
|
||||
### 修改数据库副本数
|
||||
|
||||
创建了单副本数据库后，希望改为双副本时，可通过 alter 命令来实现，反之亦然
|
||||
|
||||
```sql
|
||||
alter database <dbname> replica 2|1
|
||||
```
|
||||
|
||||
## 异常情况
|
||||
|
||||
| 异常场景 | 集群状态 |
|
||||
| ------- | ------ |
|
||||
| 没有 Vnode 发生故障： Arbitrator 故障（Mnode 宕机节点超过一个，导致 Mnode 无法选主）| **持续提供服务** |
|
||||
| 仅一个 Vnode 故障：VGroup 已经达成同步后，某一个 Vnode 才发生故障的 | **持续提供服务** |
|
||||
| 仅一个 Vnode 故障：离线 Vnode 启动后，VGroup 未达成同步前，另一个 Vnode 服务故障的 | **无法提供服务** |
|
||||
| 两个 Vnode 都发生故障 | **无法提供服务** |
|
||||
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 1. 创建双副本数据库或修改为双副本时，报错：DB error: Out of dnodes
|
||||
- 服务器节点数不足：原因是，数据服务器节点数少于两个。
|
||||
- 解决方案：增加服务器节点数量，满足最低要求。
|
||||
|
||||
### 2. 创建双副本数据库或 split vgroup 时，报错：DB error: Vnodes exhausted
|
||||
- 服务器可用 Vnodes 不足：原因是某些服务器节点可用 Vnodes 数少于建库或 split vgroup 的需求数。
|
||||
- 解决方案：调整服务器 CPU 数量、SupportVnodes 数量，满足建库要求。
|
||||
|
|
@ -1,31 +1,29 @@
|
|||
---
|
||||
title: TDengine 双活系统
|
||||
sidebar_label: 双活系统
|
||||
title: 双活方案
|
||||
sidebar_label: 双活方案
|
||||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
本节介绍 TDengine 双活系统的配置和使用。
|
||||
部分用户因为部署环境的特殊性只能部署两台服务器，同时希望实现一定的服务高可用和数据高可靠。本文主要描述基于数据复制和客户端 Failover 两项关键技术的 TDengine 双活系统的产品行为，包括双活系统的架构、配置、运维等。TDengine 双活既可以用于前面所述资源受限的环境，也可用于在两套 TDengine 集群（不限资源）之间的灾备场景。双活是 TDengine Enterprise 特有功能，在 3.3.0.0 版本中第一次发布，建议使用最新版本。
|
||||
|
||||
1. 部分用户因为部署环境的特殊性只能部署两台服务器，同时希望实现一定的服务高可用和数据高可靠。本文主要描述基于数据复制和客户端 Failover 两项关键技术的 TDengine 双活系统的产品行为，包括双活系统的架构、配置、运维等。TDengine 双活既可以用于前面所述资源受限的环境，也可用于在两套 TDengine 集群（不限资源）之间的灾备场景。双活是 TDengine Enterprise 特有功能，在 3.3.0.0 版本中第一次发布，建议使用最新版本。
|
||||
双活系统的定义是：业务系统中有且仅有两台服务器，其上分别部署一套服务，在业务层看来这两台机器和两套服务是一个完整的系统，对其中的细节业务层不需要感知。双活中的两个节点通常被称为 Master-Slave，意为”主从“或”主备“，本文档中可能会出现混用的情况。
|
||||
|
||||
2. 双活系统的定义是：业务系统中有且仅有两台服务器，其上分别部署一套服务，在业务层看来这两台机器和两套服务是一个完整的系统，对其中的细节业务层不需要感知。双活中的两个节点通常被称为 Master-Slave，意为”主从“或”主备“，本文档中可能会出现混用的情况。
|
||||
TDengine 双活系统的部署架构图如下, 其中涉及到三个关键点：
|
||||
|
||||
3. TDengine 双活系统的部署架构图如下, 其中涉及到三个关键点：
|
||||
1. 由 Client Driver 实现对双系统的 Failover，即主节点宕机时的主从切换
|
||||
2. 由 taosX 从（当前的）主节点到从节点实现数据复制
|
||||
3. 由数据订阅的写接口在写入复制过来的数据时在 WAL 中加入特殊标记，由数据订阅的读接口在读取数据时自动过滤掉带有该特殊标记的数据，避免重复复制形成 infinite loop
|
||||
|
||||
注：下图中仅以一个单机版 TDengine 作为示例，但在实际部署中图中的一个 Host 也可以被任意节点数量的 TDengine 集群代替。
|
||||
|
||||
|
||||
|
||||
|
||||
## 配置
|
||||
|
||||
### 集群配置
|
||||
## 集群配置
|
||||
|
||||
双活对 TDengine 集群本身的配置没有任何要求，但对要在双活系统之间同步的数据库的 WAL 保留时长有一定要求，WAL 保留时长越大双活系统的容错率越高；如果备节点宕机时长超过主节点上的 WAL 保留时长，必定会导致备节点上有数据缺失；如果备节点宕机时长虽未超过主节点上的 WAL 保留时长，也有一定概率丢失数据，取决于接近的程度以及数据同步的速度。
|
||||
|
||||
### 客户端配置
|
||||
## 客户端配置
|
||||
|
||||
目前只有 Java 连接器在 WebSocket 连接模式下支持双活，其配置示例如下
|
||||
|
||||
|
|
@ -42,19 +40,19 @@ connection = DriverManager.getConnection(url, properties);
|
|||
|
||||
其中的配置属性及含义如下表
|
||||
|
||||
| 属性名 | 含义 |
|
||||
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
|
||||
| PROPERTY_KEY_SLAVE_CLUSTER_HOST | 第二节点的主机名或者 ip，默认空 |
|
||||
| PROPERTY_KEY_SLAVE_CLUSTER_PORT | 第二节点的端口号，默认空 |
|
||||
| 属性名 | 含义 |
|
||||
| ---------------------------------- | --- |
|
||||
| PROPERTY_KEY_SLAVE_CLUSTER_HOST | 第二节点的主机名或者 ip，默认空 |
|
||||
| PROPERTY_KEY_SLAVE_CLUSTER_PORT | 第二节点的端口号，默认空 |
|
||||
| PROPERTY_KEY_ENABLE_AUTO_RECONNECT | 是否启用自动重连。仅在使用 WebSocket 连接时生效。true: 启用，false: 不启用。默认为 false。双活场景下请设置为 true |
|
||||
| PROPERTY_KEY_RECONNECT_INTERVAL_MS | 重连的时间间隔，单位毫秒：默认 2000 毫秒，也就是 2 秒；最小值为 0， 表示立即重试；最大值不做限制 |
|
||||
| PROPERTY_KEY_RECONNECT_RETRY_COUNT | 每节点最多重试次数：默认值为 3；最小值为 0，表示不进行重试；最大值不做限制 |
|
||||
| PROPERTY_KEY_RECONNECT_INTERVAL_MS | 重连的时间间隔，单位毫秒：默认 2000 毫秒，也就是 2 秒；最小值为 0， 表示立即重试；最大值不做限制 |
|
||||
| PROPERTY_KEY_RECONNECT_RETRY_COUNT | 每节点最多重试次数：默认值为 3；最小值为 0，表示不进行重试；最大值不做限制 |
|
||||
|
||||
### 约束条件
|
||||
## 约束条件
|
||||
|
||||
1. 应用程序不能使用订阅接口，如果配置了双活参数会导致创建消费者失败。
|
||||
2. 不建议应用程序使用参数绑定的写入和查询方式，如果使用应用需要自己解决连接切换后的相关对象失效问题。
|
||||
3. 在双活场景下，不建议用户应用程序显示调用 use database，应该在连接参数中指定 database。
|
||||
1. 应用程序不能使用订阅接口，如果配置了双活参数会导致创建消费者失败
|
||||
2. 不建议应用程序使用参数绑定的写入和查询方式，如果使用应用需要自己解决连接切换后的相关对象失效问题
|
||||
3. 在双活场景下，不建议用户应用程序显示调用 use database，应该在连接参数中指定 database
|
||||
4. 双活的两端集群必须同构（即数据库的命名和所有配置参数以及用户名密码和权限设置等完全相同）
|
||||
5. 只支持 WebSocket 连接模式
|
||||
|
||||
|
|
@ -73,7 +71,7 @@ taosx replica start
|
|||
1. 方法一
|
||||
|
||||
```shell
|
||||
- taosx replica start -f source_endpoint -t sink_endpoint [database...]
|
||||
taosx replica start -f source_endpoint -t sink_endpoint [database...]
|
||||
```
|
||||
|
||||
在本机器所在的 taosx 服务中建立从 source_endpoint 到 sink_endpoint 的同步任务。运行该命令成功后，将打印 replica ID 到控制台（后续记为 id）。
|
||||
|
|
@ -82,6 +80,7 @@ taosx replica start
|
|||
```shell
|
||||
taosx replica start -f td1:6030 -t td2:6030
|
||||
```
|
||||
|
||||
该示例命令会自动创建除 information_schema、performance_schema、log、audit 库之外的同步任务。可以使用 `http://td2:6041` 指定该 endpoint 使用 websocket 接口（默认是原生接口）。也可以指定数据库同步：taosx replica start -f td1:6030 -t td2:6030 db1 仅创建指定的数据库同步任务。
|
||||
|
||||
2. 方法二
|
||||
|
|
@ -93,9 +92,9 @@ taosx replica start -i id [database...]
|
|||
使用上面已经创建的 Replica ID (id) 以在该同步任务中增加其它数据库。
|
||||
|
||||
注意：
|
||||
- 多次使用该命令，不会创建重复任务，仅将所指定的数据库增加到相应任务中。
|
||||
- replica id 在一个 taosX 实例内是全局唯一的，与 source/sink 的组合无关
|
||||
- 为便于记忆，replica id 为一个随机常用单词，系统自动将 source/sink 组合对应到一个词库中取得一个唯一可用单词。
|
||||
1. 多次使用该命令，不会创建重复任务，仅将所指定的数据库增加到相应任务中。
|
||||
2. replica id 在一个 taosX 实例内是全局唯一的，与 source/sink 的组合无关
|
||||
3. 为便于记忆，replica id 为一个随机常用单词，系统自动将 source/sink 组合对应到一个词库中取得一个唯一可用单词。
|
||||
|
||||
### 查看任务状态
|
||||
|
||||
|
|
@ -120,8 +119,8 @@ taosx replica stop id [db...]
|
|||
```
|
||||
|
||||
该命令作用如下：
|
||||
- 停止指定 Replica ID 下所有或指定数据库的双副本同步任务。
|
||||
- 使用 `taosx replica stop id1 db1` 表示停止 id1 replica 下 db1的同步任务。
|
||||
1. 停止指定 Replica ID 下所有或指定数据库的双副本同步任务。
|
||||
2. 使用 `taosx replica stop id1 db1` 表示停止 id1 replica 下 db1的同步任务。
|
||||
|
||||
### 重启双活任务
|
||||
|
||||
|
|
@ -130,8 +129,8 @@ taosx replica restart id [db...]
|
|||
```
|
||||
|
||||
该命令作用如下：
|
||||
- 重启指定 Replica ID 下所有或指定数据库的双副本同步任务。
|
||||
- 使用 `taosx replica start id1 db1` 仅重启指定数据库 db1的同步任务。
|
||||
1. 重启指定 Replica ID 下所有或指定数据库的双副本同步任务。
|
||||
2. 使用 `taosx replica start id1 db1` 仅重启指定数据库 db1的同步任务。
|
||||
|
||||
### 查看同步进度
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
sidebar_label: 高可用
|
||||
title: 高可用
|
||||
---
|
||||
|
||||
TDengine 作为分布式时序数据库，支持高可用特性。默认高可用方案为基于 RAFT 协议的标准三副本方案；为适应不同用户场景的需要，提供基于 RAFT 协议改造的双副本方案；为满足传统双机主备架构的需求，提供基于 WAL 数据同步的双活方案。
|
||||
|
||||
- 标准三副本方案：时序数据的副本数目为 3，确保了最高的可用性，成本也最高。
|
||||
- 双副本结合 Arbitrator 方案：时序数据的副本数目为 2，但节点数目至少为 3，以确保高可用性和良好的数据一致性，可显著降低成本。与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性。
|
||||
- 双活方案：可仅部署两个节点，高可用性较好，数据一致性较弱（最终一致性）。
|
||||
|
||||
以下为三种方案的特点：
|
||||
|
||||
| # | **三副本** | **双副本** | **双活** |
|
||||
|:--|:----------|:----------|:--------|
|
||||
| **集群数目** | 部署一个集群 | 部署一个集群 | 部署两个不同集群 |
|
||||
| **最小节点数** | 三个数据节点 | 两个数据节点，一个仲裁节点 | 两个数据节点 |
|
||||
| **选主原理** | Raft 协议 | 管理节点仲裁选主 | 无需选主 |
|
||||
| **同步原理** | Raft 协议 | Raft 协议 | 通过 taosX 进行数据同步 |
|
||||
| **同步延迟** | 无延迟 | 无延迟 | 依赖于 taosX 的同步速度，秒级延迟 |
|
||||
| **数据安全性** | 无数据丢失 | 无数据丢失 | 依赖于 WAL 的保存时长 |
|
||||
| **数据一致性** | RAFT 一致性 | RAFT 一致性 | 最终一致性 |
|
||||
| **高可用性** | 任一节点宕机不影响服务 | 任一节点宕机不影响服务，但不能处理连续宕机场景 | 一个实例存活即可提供服务 |
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
|
|
@ -4,26 +4,27 @@ title: 与 Superset 集成
|
|||
---
|
||||
Apache Superset 是一个现代的企业级商业智能（BI）Web 应用程序，主要用于数据探索和可视化。它由 Apache 软件基金会支持，是一个开源项目，它拥有活跃的社区和丰富的生态系统。Apache Superset 提供了直观的用户界面，使得创建、分享和可视化数据变得简单，同时支持多种数据源和丰富的可视化选项。
|
||||
|
||||
通过 TDengine 的 Python 连接器, Superset 可支持 TDengine 数据源并提供数据展现、分析等功能
|
||||
通过 TDengine 的 Python 连接器, Apache Superset 可支持 TDengine 数据源并提供数据展现、分析等功能
|
||||
|
||||
## 安装 Apache Superset
|
||||
|
||||
确保已安装 Apache Superset v2.1.0 及以上版本, 如未安装，请到其 [官网](https://superset.apache.org/) 安装
|
||||
## 前置条件
|
||||
|
||||
## 安装 TDengine
|
||||
准备以下环境：
|
||||
- TDengine 集群已部署并正常运行（企业及社区版均可）
|
||||
- taosAdapter 能够正常运行。详细参考 [taosAdapter 使用手册](../../../reference/components/taosadapter)
|
||||
- Apache Superset v2.1.0 或以上版本已安装。安装 Apache Superset 请参考 [官方文档](https://superset.apache.org/)
|
||||
|
||||
TDengine 企业版及社区版均可支持，版本要求在 3.0 及以上
|
||||
|
||||
## 安装 TDengine Python 连接器
|
||||
|
||||
TDengine Python 连接器从 `v2.1.18` 开始自带 Superset 连接驱动，安装程序会把连接驱动安装到 Superset 相应目录下并向 Superset 提供数据源服务
|
||||
Superset 与 TDengine 之间使用 WebSocket 协议连接，所以需另安装支持 WebSocket 连接协议的组件 `taos-ws-py` , 全部安装脚本如下：
|
||||
TDengine Python 连接器从 `v2.1.18` 起带 Superset 连接驱动，会安装至 Superset 相应目录下并向 Superset 提供数据源服务
|
||||
Superset 与 TDengine 之间使用 WebSocket 协议连接，需安装支持此协议的 `taos-ws-py` 组件, 全部安装脚本如下：
|
||||
```bash
|
||||
pip3 install taospy
|
||||
pip3 install taos-ws-py
|
||||
```
|
||||
|
||||
## Superset 中配置 TDengine 连接
|
||||
## 配置 TDengine 数据源
|
||||
|
||||
**第 1 步**，进入新建数据库连接页面 "Superset" → "Setting" → "Database Connections" → "+DATABASE"
|
||||
**第 2 步**，选择 TDengine 数据库连接。"SUPPORTED DATABASES" 下拉列表中选择 "TDengine" 项。
|
||||
|
|
|
|||
|
|
@ -4,26 +4,17 @@ sidebar_label: taosdump
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
taosdump 是一个支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个运行中的 TDengine 集群中的工具应用程序。
|
||||
taosdump 是为开源用户提供的 TDengine 数据备份/恢复工具，备份数据文件采用标准 [ Apache AVRO ](https://avro.apache.org/) 格式，方便与外界生态交换数据。taosdump 提供多种数据备份及恢复选项来满足不同需求，可通过 --help 查看支持的全部选项。
|
||||
|
||||
taosdump 可以用数据库、超级表或普通表作为逻辑数据单元进行备份，也可以对数据库、超级
|
||||
表和普通表中指定时间段内的数据记录进行备份。使用时可以指定数据备份的目录路径，如果
|
||||
不指定位置，taosdump 默认会将数据备份到当前目录。
|
||||
|
||||
如果指定的位置已经有数据文件，taosdump 会提示用户并立即退出，避免数据被覆盖。这意味着同一路径只能被用于一次备份。
|
||||
如果看到相关提示，请小心操作。
|
||||
|
||||
taosdump 是一个逻辑备份工具，它不应被用于备份任何原始数据、环境设置、
|
||||
硬件信息、服务端配置或集群的拓扑结构。taosdump 使用
|
||||
[ Apache AVRO ](https://avro.apache.org/)作为数据文件格式来存储备份数据。
|
||||
|
||||
## 安装
|
||||
|
||||
taosdump 有两种安装方式:
|
||||
taosdump 提供两种安装方式:
|
||||
|
||||
- 安装 taosTools 官方安装包, 请从[发布历史页面](https://docs.taosdata.com/releases/tools/)页面找到 taosTools 并下载安装。
|
||||
- taosdump 是 TDengine 安装包中默认安装组件，安装 TDengine 后即可使用，可参考[TDengine 安装](../../../get-started/)
|
||||
|
||||
- 单独编译 taos-tools 并安装, 参考 [taos-tools](https://github.com/taosdata/taos-tools) 仓库。
|
||||
|
||||
- 单独编译 taos-tools 并安装, 详情请参考 [taos-tools](https://github.com/taosdata/taos-tools) 仓库。
|
||||
|
||||
## 常用使用场景
|
||||
|
||||
|
|
@ -31,9 +22,11 @@ taosdump 有两种安装方式:
|
|||
|
||||
1. 备份所有数据库：指定 `-A` 或 `--all-databases` 参数；
|
||||
2. 备份多个指定数据库：使用 `-D db1,db2,...` 参数；
|
||||
3. 备份指定数据库中的某些超级表或普通表：使用 `dbname stbname1 stbname2 tbname1 tbname2 ...` 参数，注意这种输入序列第一个参数为数据库名称，且只支持一个数据库，第二个和之后的参数为该数据库中的超级表或普通表名称，中间以空格分隔；
|
||||
3. 备份指定数据库中某些超级表或普通表：使用 `dbname stbname1 stbname2 tbname1 tbname2 ...` 参数，注意这种输入序列第一个参数为数据库名称，且只支持一个数据库，第二个和之后的参数为该数据库中的超级表或普通表名称，中间以空格分隔；
|
||||
4. 备份系统 log 库：TDengine 集群通常会包含一个系统数据库，名为 `log`，这个数据库内的数据为 TDengine 自我运行的数据，taosdump 默认不会对 log 库进行备份。如果有特定需求对 log 库进行备份，可以使用 `-a` 或 `--allow-sys` 命令行参数。
|
||||
5. “宽容”模式备份：taosdump 1.4.1 之后的版本提供 `-n` 参数和 `-L` 参数，用于备份数据时不使用转义字符和“宽容”模式，可以在表名、列名、标签名没使用转义字符的情况下减少备份数据时间和备份数据占用空间。如果不确定符合使用 `-n` 和 `-L` 条件时请使用默认参数进行“严格”模式进行备份。转义字符的说明请参考[官方文档](../../taos-sql/escape)。
|
||||
6. `-o` 参数指定的目录下如果已存在备份文件，为防止数据被覆盖，taosdump 会报错并退出，请更换其它空目录或清空原来数据后再备份。
|
||||
7. 目前 taosdump 不支持数据断点继备功能，一旦数据备份中断，需要从头开始。如果备份需要很长时间，建议使用（-S -E 选项）指定开始/结束时间进行分段备份的方法，
|
||||
|
||||
:::tip
|
||||
- taosdump 1.4.1 之后的版本提供 `-I` 参数，用于解析 avro 文件 schema 和数据，如果指定 `-s` 参数将只解析 schema。
|
||||
|
|
@ -45,7 +38,9 @@ taosdump 有两种安装方式:
|
|||
|
||||
### taosdump 恢复数据
|
||||
|
||||
恢复指定路径下的数据文件：使用 `-i` 参数加上数据文件所在路径。如前面提及，不应该使用同一个目录备份不同数据集合，也不应该在同一路径多次备份同一数据集，否则备份数据会造成覆盖或多次备份。
|
||||
- 恢复指定路径下的数据文件：使用 `-i` 参数加上数据文件所在路径。如前面提及，不应该使用同一个目录备份不同数据集合，也不应该在同一路径多次备份同一数据集，否则备份数据会造成覆盖或多次备份。
|
||||
- taosdump 支持数据恢复至新数据库名下，参数是 -W, 详细见命令行参数说明。
|
||||
|
||||
|
||||
:::tip
|
||||
taosdump 内部使用 TDengine stmt binding API 进行恢复数据的写入，为提高数据恢复性能，目前使用 16384 为一次写入批次。如果备份数据中有比较多列数据，可能会导致产生 "WAL size exceeds limit" 错误，此时可以通过使用 `-B` 参数调整为一个更小的值进行尝试。
|
||||
|
|
@ -108,6 +103,13 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
the table name.(Version 2.5.3)
|
||||
-T, --thread-num=THREAD_NUM Number of thread for dump in file. Default is
|
||||
8.
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
-k, --retry-count=VALUE Set the number of retry attempts for connection or
|
||||
query failures
|
||||
-z, --retry-sleep-ms=VALUE retry interval sleep time, unit ms
|
||||
-C, --cloud=CLOUD_DSN specify a DSN to access TDengine cloud service
|
||||
-R, --restful Use RESTful interface to connect TDengine
|
||||
-t, --timeout=SECONDS The timeout seconds for websocket to interact.
|
||||
|
|
@ -115,10 +117,6 @@ Usage: taosdump [OPTION...] dbname [tbname ...]
|
|||
-?, --help Give this help list
|
||||
--usage Give a short usage message
|
||||
-V, --version Print program version
|
||||
-W, --rename=RENAME-LIST Rename database name with new name during
|
||||
importing data. RENAME-LIST:
|
||||
"db1=newDB1|db2=newDB2" means rename db1 to newDB1
|
||||
and rename db2 to newDB2 (Version 2.5.4)
|
||||
|
||||
Mandatory or optional arguments to long options are also mandatory or optional
|
||||
for any corresponding short options.
|
||||
|
|
|
|||
|
|
@ -4,59 +4,59 @@ sidebar_label: taosBenchmark
|
|||
toc_max_heading_level: 4
|
||||
---
|
||||
|
||||
taosBenchmark (曾用名 taosdemo ) 是一个用于测试 TDengine 产品性能的工具。taosBenchmark 可以测试 TDengine 的插入、查询和订阅等功能的性能，它可以模拟由大量设备产生的大量数据，还可以灵活地控制数据库、超级表、标签列的数量和类型、数据列的数量和类型、子表的数量、每张子表的数据量、插入数据的时间间隔、taosBenchmark 的工作线程数量、是否以及如何插入乱序数据等。为了兼容过往用户的使用习惯，安装包提供 了 taosdemo 作为 taosBenchmark 的软链接。
|
||||
taosBenchmark 是 TDengine 产品性能基准测试工具，提供对 TDengine 产品写入、查询及订阅性能测试，输出性能指标。
|
||||
|
||||
## 安装
|
||||
|
||||
taosBenchmark 有两种安装方式:
|
||||
taosBenchmark 提供两种安装方式:
|
||||
|
||||
- 安装 TDengine 官方安装包的同时会自动安装 taosBenchmark, 详情请参考[ TDengine 安装](../../../get-started/)。
|
||||
- taosBenchmark 是 TDengine 安装包中默认安装组件，安装 TDengine 后即可使用，参考 [TDengine 安装](../../../get-started/)
|
||||
|
||||
- 单独编译 taos-tools 并安装, 详情请参考 [taos-tools](https://github.com/taosdata/taos-tools) 仓库。
|
||||
- 单独编译 taos-tools 并安装, 参考 [taos-tools](https://github.com/taosdata/taos-tools) 仓库。
|
||||
|
||||
## 运行
|
||||
|
||||
### 配置和运行方式
|
||||
### 运行方式
|
||||
|
||||
taosBenchmark 需要在操作系统的终端执行,该工具支持两种配置方式：[命令行参数](#命令行参数详解) 和 [JSON 配置文件](#配置文件参数详解)。这两种方式是互斥的，在使用配置文件时只能使用一个命令行参数 `-f <json file>` 指定配置文件。在使用命令行参数运行 taosBenchmark 并控制其行为时则不能使用 `-f` 参数而要用其它参数来进行配置。除此之外，taosBenchmark 还提供了一种特殊的运行方式，即无参数运行。
|
||||
taosBenchmark 支持三种运行模式:
|
||||
- 无参数模式
|
||||
- 命令行模式
|
||||
- JSON 配置文件模式
|
||||
`命令行方式` 为 `JSON 配置文件方式` 功能子集，两者都使用时，命令行方式优先。
|
||||
|
||||
taosBenchmark 支持对 TDengine 做完备的性能测试，其所支持的 TDengine 功能分为三大类：写入、查询和订阅。这三种功能之间是互斥的，每次运行 taosBenchmark 只能选择其中之一。值得注意的是，所要测试的功能类型在使用命令行配置方式时是不可配置的，命令行配置方式只能测试写入性能。若要测试 TDengine 的查询和订阅性能，必须使用配置文件的方式，通过配置文件中的参数 `filetype` 指定所要测试的功能类型。
|
||||
|
||||
**在运行 taosBenchmark 之前要确保 TDengine 集群已经在正确运行。**
|
||||
|
||||
### 无命令行参数运行
|
||||
|
||||
执行下列命令即可快速体验 taosBenchmark 对 TDengine 进行基于默认配置的写入性能测试。
|
||||
|
||||
```bash
|
||||
taosBenchmark
|
||||
```
|
||||
|
||||
在无参数运行时，taosBenchmark 默认连接 `/etc/taos` 下指定的 TDengine 集群，并在 TDengine 中创建一个名为 test 的数据库，test 数据库下创建名为 meters 的一张超级表，超级表下创建 10000 张表，每张表中写入 10000 条记录。注意，如果已有 test 数据库，这个命令会先删除该数据库后建立一个全新的 test 数据库。
|
||||
在无参数运行时，taosBenchmark 默认连接 `/etc/taos/taos.cfg` 中指定的 TDengine 集群。
|
||||
连接成功后，会默认创建智能电表示例数据库 test，创建超级表 meters, 创建子表 1 万，每子写入数据 1 万条，若 test 库已存在，默认会先删再建。
|
||||
|
||||
### 使用命令行配置参数运行
|
||||
|
||||
在使用命令行参数运行 taosBenchmark 并控制其行为时，`-f <json file>` 参数不能使用。所有配置参数都必须通过命令行指定。以下是使用命令行方式测试 taosBenchmark 写入性能的一个示例。
|
||||
### 使用命令行参数运行
|
||||
|
||||
命令行支持的参数为写入功能中使用较为频繁的参数，查询与订阅功能不支持命令行方式
|
||||
示例：
|
||||
```bash
|
||||
taosBenchmark -I stmt -n 200 -t 100
|
||||
taosBenchmark -d db -t 100 -n 1000 -T 4 -I stmt -y
|
||||
```
|
||||
|
||||
上面的命令 `taosBenchmark` 将创建一个名为`test`的数据库，在其中建立一张超级表`meters`，在该超级表中建立 100 张子表并使用参数绑定的方式为每张子表插入 200 条记录。
|
||||
此命令表示使用 `taosBenchmark` 将创建一个名为 `db` 的数据库，并建立默认超级表 `meters`，子表 100 ，使用参数绑定(stmt)方式为每张子表写入 1000 条记录。
|
||||
|
||||
### 使用配置文件运行
|
||||
|
||||
taosBenchmark 安装包中提供了配置文件的示例，位于 `<install_directory>/examples/taosbenchmark-json` 下
|
||||
|
||||
使用如下命令行即可运行 taosBenchmark 并通过配置文件控制其行为。
|
||||
配置文件方式运行提供了全部功能，所有命令行参数都可以在配置文件中配置运行
|
||||
|
||||
```bash
|
||||
taosBenchmark -f <json file>
|
||||
```
|
||||
|
||||
**下面是几个配置文件的示例：**
|
||||
**下面为支持的写入、查询、订阅三大功能的配置文件示例：**
|
||||
|
||||
#### 插入场景 JSON 配置文件示例
|
||||
#### 写入场景 JSON 配置文件示例
|
||||
|
||||
<details>
|
||||
<summary>insert.json</summary>
|
||||
|
|
@ -89,130 +89,102 @@ taosBenchmark -f <json file>
|
|||
|
||||
</details>
|
||||
|
||||
查看更多 json 配置文件示例可 [点击这里](https://github.com/taosdata/taos-tools/tree/main/example)
|
||||
|
||||
## 命令行参数详解
|
||||
| 命令行参数 | 功能说明 |
|
||||
| ---------------------------- | ----------------------------------------------- |
|
||||
| -f/--file \<json file> | 要使用的 JSON 配置文件，由该文件指定所有参数，本参数与命令行其他参数不能同时使用。没有默认值 |
|
||||
| -c/--config-dir \<dir> | TDengine 集群配置文件所在的目录，默认路径是 /etc/taos |
|
||||
| -h/--host \<host> | 指定要连接的 TDengine 服务端的 FQDN，默认值为 localhost |
|
||||
| -P/--port \<port> | 要连接的 TDengine 服务器的端口号，默认值为 6030 |
|
||||
| -I/--interface \<insertMode> | 插入模式，可选项有 taosc, rest, stmt, sml, sml-rest, 分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc |
|
||||
| -u/--user \<user> | 用于连接 TDengine 服务端的用户名，默认为 root |
|
||||
| -U/--supplement-insert | 写入数据而不提前建数据库和表，默认关闭 |
|
||||
| -p/--password \<passwd> | 用于连接 TDengine 服务端的密码，默认值为 taosdata |
|
||||
| -o/--output \<file> | 结果输出文件的路径，默认值为 ./output.txt |
|
||||
| -T/--thread \<threadNum> | 插入数据的线程数量，默认为 8 |
|
||||
| -B/--interlace-rows \<rowNum> |启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程，直到所有子表的数据都插入完成。默认值为 0， 即向一张子表完成数据插入后才会向下一张子表进行数据插入 |
|
||||
| -i/--insert-interval \<timeInterval> | 指定交错插入模式的插入间隔，单位为 ms，默认值为 0。 只有当 `-B/--interlace-rows` 大于 0 时才起作用 |意味着数据插入线程在为每个子表插入隔行扫描记录后，会等待该值指定的时间间隔后再进行下一轮写入 |
|
||||
| -r/--rec-per-req \<rowNum> | 每次向 TDengine 请求写入的数据行数，默认值为 30000 |
|
||||
| -t/--tables \<tableNum> | 指定子表的数量，默认为 10000 |
|
||||
| -S/--timestampstep \<stepLength> | 每个子表中插入数据的时间戳步长，单位是 ms，默认值是 1 |
|
||||
| -n/--records \<recordNum> | 每个子表插入的记录数，默认值为 10000 |
|
||||
| -d/--database \<dbName> | 所使用的数据库的名称，默认值为 test |
|
||||
| -b/--data-type \<colType> | 指定超级表普通列数据类型, 多个使用逗号分隔，默认值： "FLOAT,INT,FLOAT" 如：`taosBenchmark -b "FLOAT,BINARY(8),NCHAR(16)"`|
|
||||
| -A/--tag-type \<tagType> | 指定超级表标签列数据类型，多个使用逗号分隔，默认值： "INT,BINARY(24)" 如：`taosBenchmark -A "INT,BINARY(8),NCHAR(8)"`|
|
||||
| -l/--columns \<colNum> | 超级表的数据列的总数量。如果同时设置了该参数和 `-b/--data-type`，则最后的结果列数为两者取大。如果本参数指定的数量大于 `-b/--data-type` 指定的列数，则未指定的列类型默认为 INT， 例如: `-l 5 -b float,double`， 那么最后的列为 `FLOAT,DOUBLE,INT,INT,INT`。如果 columns 指定的数量小于或等于 `-b/--data-type` 指定的列数，则结果为 `-b/--data-type` 指定的列和类型，例如: `-l 3 -b float,double,float,bigint`，那么最后的列为 `FLOAT,DOUBLE,FLOAT,BIGINT` |
|
||||
| -L/--partial-col-num \<colNum> | 指定某些列写入数据，其他列数据为 NULL。默认所有列都写入数据 |
|
||||
| -w/--binwidth \<length> | nchar 和 binary 类型的默认长度，默认值为 64 |
|
||||
| -m/--table-prefix \<tablePrefix> | 子表名称的前缀，默认值为 "d" |
|
||||
| -E/--escape-character | 开关参数，指定在超级表和子表名称中是否使用转义字符。默认值为不使用 |
|
||||
| -C/--chinese | 开关参数，指定 nchar 和 binary 是否使用 Unicode 中文字符。默认值为不使用 |
|
||||
| -N/--normal-table | 开关参数，指定只创建普通表，不创建超级表。默认值为 false。仅当插入模式为 taosc, stmt, rest 模式下可以使用 |
|
||||
| -M/--random | 开关参数，插入数据为生成的随机值。默认值为 false。若配置此参数，则随机生成要插入的数据。对于数值类型的 标签列/数据列，其值为该类型取值范围内的随机值。对于 NCHAR 和 BINARY 类型的 标签列/数据列，其值为指定长度范围内的随机字符串 |
|
||||
| -x/--aggr-func | 开关参数，指示插入后查询聚合函数。默认值为 false |
|
||||
| -y/--answer-yes | 开关参数，要求用户在提示后确认才能继续 |默认值为 false 。
|
||||
| -O/--disorder \<Percentage> | 指定乱序数据的百分比概率，其值域为 [0,50]。默认为 0，即没有乱序数据 |
|
||||
| -R/--disorder-range \<timeRange> | 指定乱序数据的时间戳回退范围。所生成的乱序时间戳为非乱序情况下应该使用的时间戳减去这个范围内的一个随机值。仅在 `-O/--disorder` 指定的乱序数据百分比大于 0 时有效|
|
||||
| -F/--prepare_rand \<Num> | 生成的随机数据中唯一值的数量。若为 1 则表示所有数据都相同。默认值为 10000 |
|
||||
| -a/--replica \<replicaNum> | 创建数据库时指定其副本数，默认值为 1 |
|
||||
| -k/--keep-trying \<NUMBER> | 失败后进行重试的次数，默认不重试。需使用 v3.0.9 以上版本|
|
||||
| -z/--trying-interval \<NUMBER> | 失败重试间隔时间，单位为毫秒，仅在 -k 指定重试后有效。需使用 v3.0.9 以上版本 |
|
||||
| -v/--vgroups \<NUMBER> | 创建数据库时指定 vgroups 数，仅对 TDengine v3.0+ 有效|
|
||||
| -V/--version | 显示版本信息并退出。不能与其它参数混用|
|
||||
| -?/--help | 显示帮助信息并退出。不能与其它参数混用|
|
||||
|
||||
- **-f/--file \<json file>** :
|
||||
要使用的 JSON 配置文件，由该文件指定所有参数，本参数与命令行其他参数不能同时使用。没有默认值。
|
||||
|
||||
- **-c/--config-dir \<dir>** :
|
||||
TDengine 集群配置文件所在的目录，默认路径是 /etc/taos 。
|
||||
## 输出性能指标
|
||||
|
||||
- **-h/--host \<host>** :
|
||||
指定要连接的 TDengine 服务端的 FQDN，默认值为 localhost 。
|
||||
|
||||
- **-P/--port \<port>** :
|
||||
要连接的 TDengine 服务器的端口号，默认值为 6030 。
|
||||
|
||||
- **-I/--interface \<insertMode>** :
|
||||
插入模式，可选项有 taosc, rest, stmt, sml, sml-rest, 分别对应普通写入、restful 接口写入、参数绑定接口写入、schemaless 接口写入、restful schemaless 接口写入 (由 taosAdapter 提供)。默认值为 taosc。
|
||||
|
||||
- **-u/--user \<user>** :
|
||||
用于连接 TDengine 服务端的用户名，默认为 root 。
|
||||
|
||||
- **-U/--supplement-insert ** :
|
||||
写入数据而不提前建数据库和表，默认关闭。
|
||||
|
||||
- **-p/--password \<passwd>** :
|
||||
用于连接 TDengine 服务端的密码，默认值为 taosdata。
|
||||
|
||||
- **-o/--output \<file>** :
|
||||
结果输出文件的路径，默认值为 ./output.txt。
|
||||
|
||||
- **-T/--thread \<threadNum>** :
|
||||
插入数据的线程数量，默认为 8 。
|
||||
|
||||
- **-B/--interlace-rows \<rowNum>** :
|
||||
启用交错插入模式并同时指定向每个子表每次插入的数据行数。交错插入模式是指依次向每张子表插入由本参数所指定的行数并重复这个过程，直到所有子表的数据都插入完成。默认值为 0， 即向一张子表完成数据插入后才会向下一张子表进行数据插入。
|
||||
|
||||
- **-i/--insert-interval \<timeInterval>** :
|
||||
指定交错插入模式的插入间隔，单位为 ms，默认值为 0。 只有当 `-B/--interlace-rows` 大于 0 时才起作用。意味着数据插入线程在为每个子表插入隔行扫描记录后，会等待该值指定的时间间隔后再进行下一轮写入。
|
||||
|
||||
- **-r/--rec-per-req \<rowNum>** :
|
||||
每次向 TDengine 请求写入的数据行数，默认值为 30000 。
|
||||
|
||||
- **-t/--tables \<tableNum>** :
|
||||
指定子表的数量，默认为 10000 。
|
||||
|
||||
- **-S/--timestampstep \<stepLength>** :
|
||||
每个子表中插入数据的时间戳步长，单位是 ms，默认值是 1。
|
||||
|
||||
- **-n/--records \<recordNum>** :
|
||||
每个子表插入的记录数，默认值为 10000 。
|
||||
|
||||
- **-d/--database \<dbName>** :
|
||||
所使用的数据库的名称，默认值为 test 。
|
||||
|
||||
- **-b/--data-type \<colType>** :
|
||||
超级表的数据列的类型。如果不使用则默认为有三个数据列，其类型分别为 FLOAT, INT, FLOAT 。
|
||||
|
||||
- **-l/--columns \<colNum>** :
|
||||
超级表的数据列的总数量。如果同时设置了该参数和 `-b/--data-type`，则最后的结果列数为两者取大。如果本参数指定的数量大于 `-b/--data-type` 指定的列数，则未指定的列类型默认为 INT， 例如: `-l 5 -b float,double`， 那么最后的列为 `FLOAT,DOUBLE,INT,INT,INT`。如果 columns 指定的数量小于或等于 `-b/--data-type` 指定的列数，则结果为 `-b/--data-type` 指定的列和类型，例如: `-l 3 -b float,double,float,bigint`，那么最后的列为 `FLOAT,DOUBLE,FLOAT,BIGINT` 。
|
||||
|
||||
- **-L/--partial-col-num \<colNum> **：
|
||||
指定某些列写入数据，其他列数据为 NULL。默认所有列都写入数据。
|
||||
|
||||
- **-A/--tag-type \<tagType>** :
|
||||
超级表的标签列类型。nchar 和 binary 类型可以同时设置长度，例如:
|
||||
#### 写入指标
|
||||
|
||||
写入结束后会在最后两行输出总体性能指标，格式如下：
|
||||
``` bash
|
||||
SUCC: Spent 8.527298 (real 8.117379) seconds to insert rows: 10000000 with 8 thread(s) into test 1172704.41 (real 1231924.74) records/second
|
||||
SUCC: insert delay, min: 19.6780ms, avg: 64.9390ms, p90: 94.6900ms, p95: 105.1870ms, p99: 130.6660ms, max: 157.0830ms
|
||||
```
|
||||
taosBenchmark -A INT,DOUBLE,NCHAR,BINARY(16)
|
||||
第一行写入速度统计：
|
||||
- Spent: 写入总耗时，单位秒，从开始写入第一个数据开始计时到最后一条数据结束，这里表示共花了 8.527298 秒
|
||||
- real : 写入总耗时（调用引擎），此耗时已抛去测试框架准备数据时间，纯统计在引擎调用上花费的时间，示例为 8.117379 秒，8.527298 - 8.117379 = 0.409919 秒则为测试框架准备数据消耗时间
|
||||
- rows : 写入总行数，为 1000 万条数据
|
||||
- threads: 写入线程数，这里是 8 个线程同时写入
|
||||
- records/second 写入速度 = `写入总耗时`/ `写入总行数` ， 括号中 `real` 同前，表示纯引擎写入速度
|
||||
第二行单个写入延时统计：
|
||||
- min : 写入最小延时
|
||||
- avg : 写入平时延时
|
||||
- p90 : 写入延时 p90 百分位上的延时数
|
||||
- p95 : 写入延时 p95 百分位上的延时数
|
||||
- p99 : 写入延时 p99 百分位上的延时数
|
||||
- max : 写入最大延时
|
||||
通过此系列指标，可观察到写入请求延时分布情况
|
||||
|
||||
#### 查询指标
|
||||
|
||||
查询性能测试主要输出查询请求速度 QPS 指标, 输出格式如下：
|
||||
``` bash
|
||||
complete query with 3 threads and 10000 query delay avg: 0.002686s min: 0.001182s max: 0.012189s p90: 0.002977s p95: 0.003493s p99: 0.004645s SQL command: select ...
|
||||
INFO: Total specified queries: 30000
|
||||
INFO: Spend 26.9530 second completed total queries: 30000, the QPS of all threads: 1113.049
|
||||
```
|
||||
- 第一行表示 3 个线程每个线程执行 10000 次查询及查询请求延时百分位分布情况，`SQL command` 为测试的查询语句
|
||||
- 第二行表示总共完成了 10000 * 3 = 30000 次查询总数
|
||||
- 第三行表示查询总耗时为 26.9653 秒，每秒查询率(QPS)为：1113.049 次/秒
|
||||
|
||||
如果没有设置标签类型，默认是两个标签，其类型分别为 INT 和 BINARY(16)。
|
||||
注意：在有的 shell 比如 bash 命令里面 “()” 需要转义，则上述指令应为：
|
||||
#### 订阅指标
|
||||
|
||||
订阅性能测试主要输出消费者消费速度指标，输出格式如下：
|
||||
``` bash
|
||||
INFO: consumer id 0 has poll total msgs: 376, period rate: 37.592 msgs/s, total rows: 3760000, period rate: 375924.815 rows/s
|
||||
INFO: consumer id 1 has poll total msgs: 362, period rate: 36.131 msgs/s, total rows: 3620000, period rate: 361313.504 rows/s
|
||||
INFO: consumer id 2 has poll total msgs: 364, period rate: 36.378 msgs/s, total rows: 3640000, period rate: 363781.731 rows/s
|
||||
INFO: consumerId: 0, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 1, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: consumerId: 2, consume msgs: 1000, consume rows: 10000000
|
||||
INFO: Consumed total msgs: 3000, total rows: 30000000
|
||||
```
|
||||
taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
||||
```
|
||||
|
||||
- **-w/--binwidth \<length>**:
|
||||
nchar 和 binary 类型的默认长度，默认值为 64。
|
||||
|
||||
- **-m/--table-prefix \<tablePrefix>** :
|
||||
子表名称的前缀，默认值为 "d"。
|
||||
|
||||
- **-E/--escape-character** :
|
||||
开关参数，指定在超级表和子表名称中是否使用转义字符。默认值为不使用。
|
||||
|
||||
- **-C/--chinese** :
|
||||
开关参数，指定 nchar 和 binary 是否使用 Unicode 中文字符。默认值为不使用。
|
||||
|
||||
- **-N/--normal-table** :
|
||||
开关参数，指定只创建普通表，不创建超级表。默认值为 false。仅当插入模式为 taosc, stmt, rest 模式下可以使用。
|
||||
|
||||
- **-M/--random** :
|
||||
开关参数，插入数据为生成的随机值。默认值为 false。若配置此参数，则随机生成要插入的数据。对于数值类型的 标签列/数据列，其值为该类型取值范围内的随机值。对于 NCHAR 和 BINARY 类型的 标签列/数据列，其值为指定长度范围内的随机字符串。
|
||||
|
||||
- **-x/--aggr-func** :
|
||||
开关参数，指示插入后查询聚合函数。默认值为 false。
|
||||
|
||||
- **-y/--answer-yes** :
|
||||
开关参数，要求用户在提示后确认才能继续。默认值为 false 。
|
||||
|
||||
- **-O/--disorder \<Percentage>** :
|
||||
指定乱序数据的百分比概率，其值域为 [0,50]。默认为 0，即没有乱序数据。
|
||||
|
||||
- **-R/--disorder-range \<timeRange>** :
|
||||
指定乱序数据的时间戳回退范围。所生成的乱序时间戳为非乱序情况下应该使用的时间戳减去这个范围内的一个随机值。仅在 `-O/--disorder` 指定的乱序数据百分比大于 0 时有效。
|
||||
|
||||
- **-F/--prepare_rand \<Num>** :
|
||||
生成的随机数据中唯一值的数量。若为 1 则表示所有数据都相同。默认值为 10000 。
|
||||
|
||||
- **-a/--replica \<replicaNum>** :
|
||||
创建数据库时指定其副本数，默认值为 1 。
|
||||
|
||||
- ** -k/--keep-trying \<NUMBER>** : 失败后进行重试的次数，默认不重试。需使用 v3.0.9 以上版本。
|
||||
|
||||
- ** -z/--trying-interval \<NUMBER>** : 失败重试间隔时间，单位为毫秒，仅在 -k 指定重试后有效。需使用 v3.0.9 以上版本。
|
||||
|
||||
- **-v/--vgroups \<NUMBER>** :
|
||||
创建数据库时指定 vgroups 数，仅对 TDengine v3.0+ 有效。
|
||||
|
||||
- **-V/--version** :
|
||||
显示版本信息并退出。不能与其它参数混用。
|
||||
|
||||
- **-?/--help** :
|
||||
显示帮助信息并退出。不能与其它参数混用。
|
||||
- 1 ~ 3 行实时输出每个消费者当前的消费速度，`msgs/s` 表示消费消息个数，每个消息中包含多行数据，`rows/s` 表示按行数统计的消费速度
|
||||
- 4 ~ 6 行是测试完成后每个消费者总体统计，统计共消费了多少条消息，共计多少行
|
||||
- 第 7 行所有消费者总体统计，`msgs` 表示共消费了多少条消息， `rows` 表示共消费了多少行数据
|
||||
|
||||
## 配置文件参数详解
|
||||
|
||||
|
|
@ -220,7 +192,7 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
|
||||
本节所列参数适用于所有功能模式。
|
||||
|
||||
- **filetype** : 要测试的功能，可选值为 `insert`, `query` 和 `subscribe`。分别对应插入、查询和订阅功能。每个配置文件中只能指定其中之一。
|
||||
- **filetype** : 功能分类，可选值为 `insert`, `query` 和 `subscribe`。分别对应插入、查询和订阅功能。每个配置文件中只能指定其中之一。
|
||||
- **cfgdir** : TDengine 客户端配置文件所在的目录，默认路径是 /etc/taos 。
|
||||
|
||||
- **host** : 指定要连接的 TDengine 服务端的 FQDN，默认值为 localhost。
|
||||
|
|
@ -252,7 +224,7 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
|
||||
- **name** : 数据库名。
|
||||
|
||||
- **drop** : 插入前是否删除数据库，可选项为 "yes" 或者 "no", 为 "no" 时不创建。默认删除。
|
||||
- **drop** : 数据库已存在时是否删除重建，可选项为 "yes" 或 "no", 默认为 “yes”
|
||||
|
||||
#### 流式计算相关配置参数
|
||||
|
||||
|
|
@ -331,21 +303,6 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
- **repeat_ts_max** : 数值类型，复合主键开启情况下指定生成相同时间戳记录的最大个数
|
||||
- **sqls** : 字符串数组类型，指定超级表创建成功后要执行的 sql 数组，sql 中指定表名前面要带数据库名，否则会报未指定数据库错误
|
||||
|
||||
#### tsma配置参数
|
||||
|
||||
指定tsma的配置参数在 `super_tables` 中的 `tsmas` 中，具体参数如下。
|
||||
|
||||
- **name** : 指定 tsma 的名字，必选项。
|
||||
|
||||
- **function** : 指定 tsma 的函数，必选项。
|
||||
|
||||
- **interval** : 指定 tsma 的时间间隔，必选项。
|
||||
|
||||
- **sliding** : 指定 tsma 的窗口时间位移，必选项。
|
||||
|
||||
- **custom** : 指定 tsma 的创建语句结尾追加的自定义配置，可选项。
|
||||
|
||||
- **start_when_inserted** : 指定当插入多少行时创建 tsma，可选项，默认为 0。
|
||||
|
||||
#### 标签列与数据列配置参数
|
||||
|
||||
|
|
@ -415,7 +372,8 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
查询场景下 `filetype` 必须设置为 `query`。
|
||||
`query_times` 指定运行查询的次数，数值类型
|
||||
|
||||
查询场景可以通过设置 `kill_slow_query_threshold` 和 `kill_slow_query_interval` 参数来控制杀掉慢查询语句的执行，threshold 控制如果 exec_usec 超过指定时间的查询将被 taosBenchmark 杀掉，单位为秒；interval 控制休眠时间，避免持续查询慢查询消耗 CPU ，单位为秒。
|
||||
查询场景可以通过设置 `kill_slow_query_threshold` 和 `kill_slow_query_interval` 参数来控制杀掉慢查询语句的执行，threshold 控制如果 exec_usec 超过指定时间的查询将被 taosBenchmark 杀掉，单位为秒；
|
||||
interval 控制休眠时间，避免持续查询慢查询消耗 CPU ，单位为秒。
|
||||
|
||||
其它通用参数详见[通用配置参数](#通用配置参数)。
|
||||
|
||||
|
|
@ -423,6 +381,11 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
|
||||
查询指定表（可以指定超级表、子表或普通表）的配置参数在 `specified_table_query` 中设置。
|
||||
|
||||
- **mixed_query** : 查询模式，取值 “yes” 为`混合查询`， "no" 为`正常查询` , 默认值为 “no”
|
||||
`混合查询`：`sqls` 中所有 sql 按 `threads` 线程数分组，每个线程执行一组， 线程中每个 sql 都需执行 `query_times` 次查询
|
||||
`正常查询`：`sqls` 中每个 sql 启动 `threads` 个线程，每个线程执行完 `query_times` 次后退出，下个 sql 需等待上个 sql 线程全部执行完退出后方可执行
|
||||
不管 `正常查询` 还是 `混合查询` ，执行查询总次数是相同的 ，查询总次数 = `sqls` 个数 * `threads` * `query_times`， 区别是 `正常查询` 每个 sql 都会启动 `threads` 个线程，而 `混合查询` 只启动一次 `threads` 个线程执行完所有 SQL, 两者启动线程次数不一样。
|
||||
|
||||
- **query_interval** : 查询时间间隔，单位是秒，默认值为 0。
|
||||
|
||||
- **threads** : 执行查询 SQL 的线程数，默认值为 1。
|
||||
|
|
@ -434,6 +397,7 @@ taosBenchmark -A INT,DOUBLE,NCHAR,BINARY\(16\)
|
|||
#### 查询超级表的配置参数
|
||||
|
||||
查询超级表的配置参数在 `super_table_query` 中设置。
|
||||
超级表查询的线程模式与上面介绍的指定查询语句查询的 `正常查询` 模式相同，不同之处是本 `sqls` 使用所有子表填充。
|
||||
|
||||
- **stblname** : 指定要查询的超级表的名称，必填。
|
||||
|
||||
|
|
|
|||
|
|
@ -325,8 +325,50 @@ TDengine 采用了一种数据驱动的策略来实现缓存数据的持久化
|
|||
|
||||
### 多级存储与对象存储
|
||||
|
||||
在默认情况下，TDengine 将所有数据存储在 /var/lib/taos 目录中。为了扩展存储容量，减少文件读取可能导致的瓶颈，并提升数据吞吐量，TDengine 允许通过配置参数dataDir，使得集群能够同时利用挂载的多块硬盘。
|
||||
说明：多级存储功能仅企业版支持，从 2.0.16.0 版本开始提供。
|
||||
|
||||
此外，TDengine 还提供了数据分级存储的功能，允许用户将不同时间段的数据存储在不同存储设备的目录中，以此实现将“热”数据和“冷”数据分开存储。这样做可以充分利用各种存储资源，同时节约成本。例如，对于最新采集且需要频繁访问的数据，由于其读取性能要求较高，用户可以配置将这些数据存储在高性能的固态硬盘上。而对于超过一定期限、查询需求较低的数据，则可以将其存储在成本相对较低的机械硬盘上。
|
||||
在默认配置下，TDengine 会将所有数据保存在 /var/lib/taos 目录下，而且每个 vnode 的数据文件保存在该目录下的不同目录。为扩大存储空间，尽量减少文件读取的瓶颈，提高数据吞吐率 TDengine 可通过配置系统参数 dataDir 让多个挂载的硬盘被系统同时使用。
|
||||
|
||||
为了进一步降低存储成本，TDengine 还支持将时序数据存储在对象存储系统中。通过其创新性的设计，在大多数情况下，从对象存储系统中查询时序数据的性能接近本地硬盘的一半，而在某些场景下，性能甚至可以与本地硬盘相媲美。同时，TDengine 还允许用户对存储在对象存储中的时序数据执行删除和更新操作。
|
||||
除此之外，TDengine 也提供了数据分级存储的功能，将不同时间段的数据存储在挂载的不同介质上的目录里，从而实现不同“热度”的数据存储在不同的存储介质上，充分利用存储，节约成本。比如，最新采集的数据需要经常访问，对硬盘的读取性能要求高，那么用户可以配置将这些数据存储在 SSD 盘上。超过一定期限的数据，查询需求量没有那么高，那么可以存储在相对便宜的 HDD 盘上。
|
||||
|
||||
多级存储支持 3 级，每级最多可配置 128 个挂载点。
|
||||
|
||||
TDengine 多级存储配置方式如下（在配置文件/etc/taos/taos.cfg 中）：
|
||||
|
||||
```
|
||||
dataDir [path] <level> <primary> <disable_create_new_file>
|
||||
```
|
||||
|
||||
- path: 挂载点的文件夹路径
|
||||
- level: 介质存储等级，取值为 0，1，2。
|
||||
0 级存储最新的数据，1 级存储次新的数据，2 级存储最老的数据，省略默认为 0。
|
||||
各级存储之间的数据流向：0 级存储 -> 1 级存储 -> 2 级存储。
|
||||
同一存储等级可挂载多个硬盘，同一存储等级上的数据文件分布在该存储等级的所有硬盘上。
|
||||
需要说明的是，数据在不同级别的存储介质上的移动，是由系统自动完成的，用户无需干预。
|
||||
- primary: 是否为主挂载点，0（否）或 1（是），省略默认为 1。
|
||||
- disable_create_new_file: 是否禁止创建新文件组，0（否）或 1（是），省略默认为 0。
|
||||
|
||||
在配置中，只允许一个主挂载点的存在（level=0，primary=1），例如采用如下的配置方式：
|
||||
|
||||
```
|
||||
dataDir /mnt/data1 0 1 0
|
||||
dataDir /mnt/data2 0 0 0
|
||||
dataDir /mnt/data3 1 0 0
|
||||
dataDir /mnt/data4 1 0 1
|
||||
dataDir /mnt/data5 2 0 0
|
||||
dataDir /mnt/data6 2 0 0
|
||||
```
|
||||
|
||||
您可以使用以下命令动态修改 dataDir 的 disable 来控制当前目录是否开启 disable_create_new_file 。
|
||||
```
|
||||
alter dnode 1 "/mnt/disk2/taos 1";
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
1. 多级存储不允许跨级配置，合法的配置方案有：仅 0 级，仅 0 级+ 1 级，以及 0 级+ 1 级+ 2 级。而不允许只配置 level=0 和 level=2，而不配置 level=1。
|
||||
2. 禁止手动移除使用中的挂载盘，挂载盘目前不支持非本地的网络盘。
|
||||
3. 多级存储目前不支持删除已经挂载的硬盘的功能。
|
||||
4. 0 级存储至少存在一个 disable_create_new_file 为 0 的挂载点，1 级 和 2 级存储没有该限制。
|
||||
|
||||
:::
|
||||
|
|
@ -509,6 +509,9 @@ int32_t qBindStmtTagsValue2(void* pBlock, void* boundTags, int64_t suid, const c
|
|||
STag* pTag = NULL;
|
||||
|
||||
for (int c = 0; c < tags->numOfBound; ++c) {
|
||||
if (bind == NULL) {
|
||||
break;
|
||||
}
|
||||
if (bind[c].is_null && bind[c].is_null[0]) {
|
||||
continue;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -70,10 +70,10 @@ require (
|
|||
github.com/ugorji/go/codec v1.2.12 // indirect
|
||||
github.com/yusufpapurcu/wmi v1.2.2 // indirect
|
||||
golang.org/x/arch v0.7.0 // indirect
|
||||
golang.org/x/crypto v0.21.0 // indirect
|
||||
golang.org/x/crypto v0.31.0 // indirect
|
||||
golang.org/x/net v0.23.0 // indirect
|
||||
golang.org/x/sys v0.24.0 // indirect
|
||||
golang.org/x/text v0.14.0 // indirect
|
||||
golang.org/x/sys v0.28.0 // indirect
|
||||
golang.org/x/text v0.21.0 // indirect
|
||||
google.golang.org/protobuf v1.33.0 // indirect
|
||||
gopkg.in/ini.v1 v1.66.4 // indirect
|
||||
gopkg.in/yaml.v2 v2.4.0 // indirect
|
||||
|
|
|
|||
|
|
@ -424,8 +424,8 @@ golang.org/x/crypto v0.0.0-20210314154223-e6e6c4f2bb5b/go.mod h1:T9bdIzuCu7OtxOm
|
|||
golang.org/x/crypto v0.0.0-20210421170649-83a5a9bb288b/go.mod h1:T9bdIzuCu7OtxOm1hfPfRQxPLYneinmdGuTeoZ9dtd4=
|
||||
golang.org/x/crypto v0.0.0-20210616213533-5ff15b29337e/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
|
||||
golang.org/x/crypto v0.0.0-20211108221036-ceb1ce70b4fa/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
|
||||
golang.org/x/crypto v0.21.0 h1:X31++rzVUdKhX5sWmSOFZxx8UW/ldWx55cbf08iNAMA=
|
||||
golang.org/x/crypto v0.21.0/go.mod h1:0BP7YvVV9gBbVKyeTG0Gyn+gZm94bibOW5BjDEYAOMs=
|
||||
golang.org/x/crypto v0.31.0 h1:ihbySMvVjLAeSH1IbfcRTkD/iNscyz8rGzjF/E5hV6U=
|
||||
golang.org/x/crypto v0.31.0/go.mod h1:kDsLvtWBEx7MV9tJOj9bnXsPbxwJQ6csT/x4KIN4Ssk=
|
||||
golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
|
||||
golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
|
||||
golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
|
||||
|
|
@ -573,8 +573,8 @@ golang.org/x/sys v0.0.0-20220128215802-99c3d69c2c27/go.mod h1:oPkhp1MJrh7nUepCBc
|
|||
golang.org/x/sys v0.0.0-20220412211240-33da011f77ad/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.24.0 h1:Twjiwq9dn6R1fQcyiK+wQyHWfaz/BJB+YIpzU/Cv3Xg=
|
||||
golang.org/x/sys v0.24.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
|
||||
golang.org/x/sys v0.28.0 h1:Fksou7UEQUWlKvIdsqzJmUmCX3cZuD2+P3XyyzwMhlA=
|
||||
golang.org/x/sys v0.28.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
|
||||
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
|
||||
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
|
||||
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
|
||||
|
|
@ -583,8 +583,8 @@ golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
|
|||
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
|
||||
golang.org/x/text v0.3.4/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
|
||||
golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
|
||||
golang.org/x/text v0.14.0 h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ=
|
||||
golang.org/x/text v0.14.0/go.mod h1:18ZOQIKpY8NJVqYksKHtTdi31H5itFRjB5/qKTNYzSU=
|
||||
golang.org/x/text v0.21.0 h1:zyQAAkrwaneQ066sspRyJaG9VNi/YJ1NfzcGB3hZ/qo=
|
||||
golang.org/x/text v0.21.0/go.mod h1:4IBbMaMmOPCJ8SecivzSH54+73PCFmPWxNTLm+vZkEQ=
|
||||
golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
|
|
|
|||
Loading…
Reference in New Issue