Doc 2978 internal kafka tls 4.3

modules/API/pages/built-in-endpoints.adoc

@@ -955,7 +955,7 @@ This request requires the privilege `WRITE_USER`:
 
 [.wrap,console]
 ----
-curl -X DELETE "https://localhost:14240/expiredtoken"
+curl --user example_username:example_password -X DELETE https://localhost:14240/gsqlserver/gsql/expiredtoken
 ----
 
 The following request deletes all expired tokens that belong to users `u1` and `u2` as well as all tokens created with secrets `s1` and `s2`.
@@ -2873,7 +2873,7 @@ The xref:built-in-endpoints.adoc#_check_query_status_detached_mode[results] and
 
 `POST /gsql/v1/queries/interpret`
 
-This endpoint runs a GSQL query in Interpreted Mode. The query body should be supplied at the data payload, and the query's parameters are supplied as the URL's query string. *This endpoint exists on the GSQL server on port 14240.*
+This endpoint runs a GSQL query in Interpreted Mode. The query body should be supplied as the data payload, and the query parameters are supplied as the URL's query string. *This endpoint exists on the GSQL server on port 14240.*
 
 This request goes directly to the GSQL server (port 14240) instead of the RESTPP server, so the username and password must be specified in the header. If you are using curl, you can use the `-u` option as shown below.
 
@@ -2886,20 +2886,47 @@ The request body for this endpoint should be the entire `INTERPRET QUERY` statem
 When running an interpreted query through this endpoint, the query parameters should be xref:index.adoc#_query_string_parameters[passed in through the URL query string].
 
 ==== Sample request:
-
+[tabs]
+====
+Request::
++
+--
 [source.wrap,bash]
 ----
-curl --fail -u <my_username>:<my_password> -X POST "http://localhost:14240/gsql/v1/queries/interpret?a=10" -d 'INTERPRET QUERY (INT a) FOR GRAPH gsql_demo {
+curl -u <my_username>:<my_password> -H "Content-Type: text/plain" -X POST "http://localhost:14240/gsql/v1/queries/interpret?a=10" -d 'INTERPRET QUERY (INT a) FOR GRAPH gsql_demo {
     PRINT a;
- }'
+}'
+----
+--
+Response::
++
+--
+[source,json]
 ----
+{
+    "error": false,
+    "message": "",
+    "version": {
+        "schema": 3,
+        "edition": "enterprise",
+        "api": "v2"
+    },
+    "results": [
+        {
+            "a": 10
+        }
+    ]
+}
+----
+--
+====
 
 === List running queries of a graph
 
 `GET /restpp/showprocesslist/{graph_name}`
 
 This endpoint reports statistics of running queries of a graph: the query's request ID, start time, expiration time, and the REST endpoint's URL.
-This includes installed queries. interpreted queries, as well as built-in queries.
+This includes installed queries, interpreted queries, as well as built-in queries.
 
 As of 4.2.1, this endpoint reports on the activity on all server nodes in a distributed cluster, not just for the node being addressed.
 
@@ -2964,7 +2991,7 @@ If set to `true`, the response will only include the status of queries on the cu
 `GET /restpp/showprocesslistall`
 
 This endpoint reports the statistics of all running queries across all graphs on a TigerGraph instance: the query's request ID, start time, expiration time, and the REST endpoint's URL.
-This includes installed queries. interpreted queries, as well as built-in queries.
+This includes installed queries, interpreted queries, as well as built-in queries.
 
 As of 4.2.1, this endpoint reports on the activity on all server nodes in a distributed cluster, not just for the node being addressed.
 

modules/API/pages/gsql-endpoints.adoc

@@ -1727,7 +1727,7 @@ Sample Response::
 '''
 === run an existing schema change job
 
-`POST /gsql/v1/schema/jobs/{jobName}`
+`PUT /gsql/v1/schema/jobs/{jobName}`
 
 Run an existing schema change job.
 
@@ -2055,7 +2055,7 @@ Sample Response::
 ====
 
 '''
-
+[#_run_a_loading_job]
 === Run a loading job
 
 `POST /gsql/v1/loading-jobs/run`
@@ -2185,19 +2185,26 @@ Sample Response::
 
 `GET /gsql/v1/loading-jobs/status`
 
-Get the status of one or more loading jobs that have been started, equivalent to GSQL
+Get the status of one or more loading jobs that have been started. This endpoint is equivalent to the GSQL command.
 xref:{page-component-version}@gsql-ref:ddl-and-loading:managing-loading-job.adoc#_show_loading_status[SHOW LOADING STATUS].
 
+The `graph` parameter is required because loading job run IDs are scoped to a specific graph.
+If the `graph` parameter is missing, the request will fail even if valid `jobIds` are provided.
+
 ==== Parameters:
 
 //[width="100%",cols="25%,25%,50%",options="header",]
 [%autowidth]
 |===
 | Name | Required | Description
 
+| `graph`
+| Yes
+| Name of the graph on which the loading jobs were executed.
+
 | `jobIds`
-| yes
-| ID of the loading job
+| Yes
+| One or more loading job run IDs, separated by commas.
 |===
 
 ==== Example
@@ -2210,7 +2217,7 @@ Sample Request::
 [source,bash]
 ----
 curl -H 'Content-Type: application/json' -X GET
-'http://localhost:14240/gsql/v1/loading-jobs/status/jobIds=financialGraph.load_ldbc_snb.jdbc.all.1111111111121'
+'http://localhost:14240/gsql/v1/loading-jobs/status?graph=financialGraph&jobIds=financialGraph.load_ldbc_snb.jdbc.all.1111111111121'
 ----
 --
 Sample Response::
@@ -2239,9 +2246,13 @@ The behavior of this endpoint is the same as that of `GET /gsql/v1/loading-jobs/
 |===
 | Name | Required | Description
 
+| `graph`
+| Yes
+| Name of the graph on which the loading job was executed.
+
 | `jobId`
-| yes
-| ID of the loading job
+| Yes
+| ID of the loading job run.
 |===
 
 ==== Example
@@ -2254,7 +2265,7 @@ Sample Request::
 [source,bash]
 ----
 curl -H 'Content-Type: application/json' -X GET
-'http://localhost:14240/gsql/v1/loading-jobs/status/financialGraph.load_ldbc_snb.jdbc.all.1111111111121'
+'http://localhost:14240/gsql/v1/loading-jobs/status/financialGraph.load_ldbc_snb.jdbc.all.1111111111121?graph=financialGraph'
 ----
 --
 Sample Response::
@@ -2708,11 +2719,11 @@ Sample Response::
 ====
 
 '''
-=== get the sample data of S3 file.uris or local files
+=== get sample data from an S3 object
 
 `POST /gsql/v1/sample-data`
 
-Get the sample data of S3 file.uris or local files.
+Get the first N lines from an S3 object
 
 ==== Parameters:
 

modules/API/pages/index.adoc

@@ -324,8 +324,8 @@ You can specify the response size limit of an HTTP request with the following he
 ----
 curl -X <GET/POST> -H "RESPONSE-LIMIT: <size limit in byte>" '<request_URL>'
 ----
-
-If the response size is larger than the given limit, an error message will be returned instead of the actual query result:
+* If the `RESPONSE-LIMIT` header is not set, TigerGraph uses the value configured in `GSQL.QueryResponseMaxSizeByte` as the default response size limit.
+* If the response size is larger than the given limit, an error message will be returned instead of the actual query result:
 
 [source,bash]
 ----

modules/additional-resources/nav.adoc

@@ -1,24 +1,6 @@
-* Additional Resources
-** xref:best-practice-guides/best-practices-overview.adoc[]
-*** xref:best-practice-guides/best-prac-scaling-clusters.adoc[Scaling Guide]
-** Troubleshooting and FAQs
-*** link:https://kb.tigergraph.com/[Knowledge base and FAQs]
-*** xref:troubleshooting:troubleshooting-guide.adoc[]
-*** xref:troubleshooting:system-administration-faqs.adoc[]
-*** xref:troubleshooting:log-files.adoc[]
-**** xref:troubleshooting:audit-log.adoc[]
-**** xref:troubleshooting:gcollect.adoc[]
-**** xref:troubleshooting:elk-filebeat.adoc[]
-** References
-*** xref:reference:configuration-parameters.adoc[]
-*** xref:reference:return-codes.adoc[]
-*** xref:user-access:rbac-row-policy/row-policy-privileges-table.adoc[]
-*** xref:reference:list-of-privileges-legacy.adoc[]
-*** xref:reference:ports.adoc[]
-*** xref:reference:glossary.adoc[]
-*** xref:reference:patents-and-third-party-software.adoc[]
-*** xref:additional-resources:legacy-tg-versions.adoc[]
-*** xref:intro:comparison-of-editions.adoc[]
-*** xref:intro:release-process.adoc[Release and Patch Process]
-*** xref:user-access:rbac-row-policy/row-policy-ebnf.adoc[]
+// NOTE: /additional-resources/nav.adoc is not used; its content is covered by /reference/nav.adoc.
+//* Additional Resources
+//** xref:best-practice-guides/best-practices-overview.adoc[]
+//*** xref:best-practice-guides/best-prac-scaling-clusters.adoc[Scaling Guide]
+//** xref:additional-resources:legacy-tg-versions.adoc[]
 

modules/additional-resources/pages/legacy-tg-versions.adoc

@@ -9,8 +9,6 @@ This page lists all LTS (Long-Term Support) and previous versions of TigerGraph
 * xref:4.1@tigergraph-server:intro:index.adoc[4.1]
 * xref:3.11@tigergraph-server:intro:index.adoc[3.11]
 * xref:3.10@tigergraph-server:intro:index.adoc[3.10]
-* xref:3.9@tigergraph-server:intro:index.adoc[3.9] (no updates planned)
-* xref:3.6@tigergraph-server:intro:index.adoc[3.6] (no updates planned)
 
 == Other Versions
 

modules/advanced-topics/nav.adoc

@@ -55,6 +55,7 @@
 //HA
 *** xref:cluster-and-ha-management:ha-overview.adoc[High Availability (HA)]
 **** xref:cluster-and-ha-management:ha-cluster.adoc[Cluster Configuration]
+**** xref:cluster-and-ha-management:node-replacement-v2.adoc[Node Replacement (V2)]
 **** xref:cluster-and-ha-management:region-aware.adoc[Region Aware Cluster Configuration]
 **** xref:cluster-and-ha-management:ha-for-gsql-server.adoc[GSQL Server HA]
 **** xref:cluster-and-ha-management:ha-for-application-server.adoc[Application Server HA]

modules/backup-and-restore/pages/configurations.adoc

@@ -91,6 +91,12 @@ S3 Role ARN takes priority over access keys. For more information, see link:http
 |System.Backup.CompressionLevel |The backup compression level strikes a balance between size and speed. The better compression, the longer it takes.
 ("BestSpeed", "DefaultCompression", "BestCompression")
 | "DefaultCompression"
+
+|System.Backup.StagingPath | Specifies the root directory for storing intermediate (staging) files during backup and restore operations. If left empty, a default `backup` folder under the TigerGraph data root is used. 
+You can override this configuration by providing the `--staging-path` option when running the `gadmin backup create` or `gadmin backup restore` commands. The command-line option takes precedence over the system configuration.
+Since these operations are I/O-intensive, we recommend setting this path to a dedicated disk separate from the TigerGraph data root directory. This helps minimize potential impact on business operations, especially during backups.
+| `"" (empty string)`
+
 |===
 
 == Backup to AWS S3

modules/cluster-and-ha-management/nav.adoc

@@ -14,6 +14,7 @@
 // HA
 ** xref:ha-overview.adoc[High Availability]
 *** xref:ha-cluster.adoc[]
+*** xref:cluster-and-ha-management:node-replacement-v2.adoc[Node Replacement (V2)]
 *** xref:region-aware.adoc[Region Aware Cluster Configuration (Preview)]
 *** xref:ha-for-gsql-server.adoc[GSQL Server HA]
 *** xref:ha-for-application-server.adoc[Application Server HA]

modules/cluster-and-ha-management/pages/expand-a-cluster.adoc

@@ -81,18 +81,35 @@ We suggest naming the new nodes following the convention of `m<count>`, such as
 
 ==== Supply a staging location
 
-Extra disk space is required during cluster expansion. If more space is not available on the same disk, you can supply a staging location on a different disk to hold temporary data:
+Extra disk space is required during cluster expansion. If more space is not available on the existing disk, you can supply a staging location on a different disk to hold temporary data:
 
 [source,console]
 ----
-$ gadmin cluster expand m3:192.168.1.3,m4:192.168.1.4 --stagingPath /tmp/
+$ gadmin cluster expand m3:192.168.1.3,m4:192.168.1.4 --staging-path /tmp/
 ----
 
-If you choose to supply a staging location, make sure that the TigerGraph Linux user has write permission to the path you provide. The overall amount of space required for expansion on each node is `(1 + ceiling(oldPartition/newPartition) ) * dataRootSize`.
-`oldPartition` and `newPartition` stand for the partitioning factors of the cluster before and after expansion, respectively; `dataRootSize` stands for the size of the data root folder on the node.
+When you specify `--staging-path`, the path must:
 
-For example, assume you are expanding from a 6-node cluster with a replication factor of 2 and a partitioning factor of 3, to a 10-node cluster with a replication factor of 2 and a partitioning factor of 5, and the size of the data root folder on a node is 50GB.
-You would need more than `(1 + ceiling(3/5)) * 50) = 100 GB` of free space on the staging path.
+* Exist on *every node* in the cluster (both existing nodes and newly added nodes).
+* Be accessible and writable by the TigerGraph Linux user on all nodes.
+
+TigerGraph uses the staging path on each node during expansion, so the operation will fail if the path is missing or not writable on any node.
+
+The overall amount of space required on each node is:
+
+`(1 + ceiling(oldPartition / newPartition)) * dataRootSize`
+
+where:
+
+* `oldPartition` = partitioning factor before expansion
+* `newPartition` = partitioning factor after expansion
+* `dataRootSize` = size of the data root folder on that node
+
+For example, expanding from a 6-node cluster with replication factor 2 and partitioning factor 3 to a 10-node cluster with replication factor 2 and partitioning factor 5, with a 50 GB data root folder, requires more than:
+
+`(1 + ceiling(3 / 5)) * 50 = 100 GB`
+
+of free space on the staging path of *each node*.
 
 ==== Configure region awareness