summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorIvan Blinkov <[email protected]>2024-07-18 13:40:16 +0700
committerGitHub <[email protected]>2024-07-18 06:40:16 +0000
commit5ff39baa13338aa0310607be94962a86af5d7953 (patch)
treef32ce4a8534b88e5df71a70c71110cd9e4e3c86c
parent8bf578994995af10f313620b37817be8e2dfc4a2 (diff)
[docs] en translation debts (#5569)
-rw-r--r--ydb/docs/en/core/concepts/datamodel/external_data_source.md37
-rw-r--r--ydb/docs/en/core/concepts/datamodel/external_table.md35
-rw-r--r--ydb/docs/en/core/concepts/datamodel/secrets.md28
-rw-r--r--ydb/docs/en/core/maintenance/manual/replacing_nodes.md81
4 files changed, 177 insertions, 4 deletions
diff --git a/ydb/docs/en/core/concepts/datamodel/external_data_source.md b/ydb/docs/en/core/concepts/datamodel/external_data_source.md
index 3f37eb7224d..f9f73a3ddf7 100644
--- a/ydb/docs/en/core/concepts/datamodel/external_data_source.md
+++ b/ydb/docs/en/core/concepts/datamodel/external_data_source.md
@@ -1 +1,36 @@
-{% include [no-translation](../../_includes/alerts/no-translation.md) %} \ No newline at end of file
+# External data sources
+
+{% note warning %}
+
+This functionality is in "Experimental" mode.
+
+{% endnote %}
+
+An external data source is an object in {{ ydb-full-name }} that describes the connection parameters to an external data source. For example, in the case of ClickHouse, the external data source describes the network address, login, and password for authentication in the ClickHouse cluster. In the case of S3 ({{ objstorage-name }}), it describes the access credentials and the path to the bucket.
+
+The following example demonstrates creating an external data source pointing to a ClickHouse cluster:
+
+```sql
+CREATE EXTERNAL DATA SOURCE test_data_source WITH (
+ SOURCE_TYPE="ClickHouse",
+ LOCATION="192.168.1.1:8123",
+ DATABASE_NAME="default",
+ AUTH_METHOD="BASIC",
+ USE_TLS="TRUE",
+ LOGIN="login",
+ PASSWORD_SECRET_NAME="test_password_name"
+)
+```
+
+After creating an external data source, you can read data from the created `EXTERNAL DATA SOURCE` object. The example below illustrates reading data from the `test_table` table in the `default` database in the ClickHouse cluster:
+
+```sql
+SELECT * FROM test_data_source.test_table
+```
+
+External data sources allow execution of [federated queries](../federated_query/index.md) for cross-system data analytics tasks.
+
+The following data sources can be used:
+- [ClickHouse](../federated_query/clickhouse.md)
+- [PostgreSQL](../federated_query/postgresql.md)
+- [Connections to S3 ({{ objstorage-name }})](../federated_query/s3/external_data_source.md) \ No newline at end of file
diff --git a/ydb/docs/en/core/concepts/datamodel/external_table.md b/ydb/docs/en/core/concepts/datamodel/external_table.md
index 3f37eb7224d..19b8cb54e4c 100644
--- a/ydb/docs/en/core/concepts/datamodel/external_table.md
+++ b/ydb/docs/en/core/concepts/datamodel/external_table.md
@@ -1 +1,34 @@
-{% include [no-translation](../../_includes/alerts/no-translation.md) %} \ No newline at end of file
+# External tables
+
+{% note warning %}
+
+This functionality is in "Preview" mode.
+
+{% endnote %}
+
+Some [external data sources](external_data_source.md), such as database management systems, store data in a structured format, while others, like S3 ({{objstorage-full-name}}), store data as individual files. To work with file-based data sources, you need to understand both the file placement rules and the formats of the stored data.
+
+A special entity, `EXTERNAL TABLE,` describes the stored data in such sources. External tables allow you to define the schema of the stored files and the schema of file placement within the source.
+
+A record in YQL might look like this:
+
+```sql
+CREATE EXTERNAL TABLE s3_test_data (
+ key Utf8 NOT NULL,
+ value Utf8 NOT NULL
+) WITH (
+ DATA_SOURCE="bucket",
+ LOCATION="folder",
+ FORMAT="csv_with_names",
+ COMPRESSION="gzip"
+);
+```
+
+Data can be inserted into external tables just like regular tables. For example, to write data to an external table, you need to execute the following query:
+
+```sql
+INSERT INTO s3_test_data
+SELECT * FROM Table
+```
+
+More details on working with external tables describing S3 buckets ({{ objstorage-name }}) can be found in section [{#T}](../federated_query/s3/external_table.md). \ No newline at end of file
diff --git a/ydb/docs/en/core/concepts/datamodel/secrets.md b/ydb/docs/en/core/concepts/datamodel/secrets.md
index 3f37eb7224d..f5f969a89ac 100644
--- a/ydb/docs/en/core/concepts/datamodel/secrets.md
+++ b/ydb/docs/en/core/concepts/datamodel/secrets.md
@@ -1 +1,27 @@
-{% include [no-translation](../../_includes/alerts/no-translation.md) %} \ No newline at end of file
+# Secrets
+
+To work with external data sources in {{ ydb-full-name }}, [federated queries](../federated_query/index.md) are used. Federated queries utilize various access credentials for authentication in external systems. These credentials are stored in separate objects called secrets. Secrets are only available for writing and updating; their values cannot be retrieved.
+
+{% note warning %}
+
+The current syntax for working with secrets is temporary and will be changed in future releases of {{ ydb-full-name }}.
+
+{% endnote %}
+
+## Creating secrets { #create_secret }
+
+Secrets are created using an SQL query:
+
+```sql
+CREATE OBJECT `MySecretName` (TYPE SECRET) WITH value=`MySecretData`;
+```
+
+## Access management { #secret_access }
+
+All rights to use the secret belong to its creator. The creator can grant another user read access to the secret through [access management](#secret_access) for secrets.
+
+Special objects called `SECRET_ACCESS` are used to manage access to secrets. To grant permission to use the secret `MySecretName` to the user `another_user`, a `SECRET_ACCESS` object named `MySecretName:another_user` must be created.
+
+```sql
+CREATE OBJECT `MySecretName:another_user` (TYPE SECRET_ACCESS)
+``` \ No newline at end of file
diff --git a/ydb/docs/en/core/maintenance/manual/replacing_nodes.md b/ydb/docs/en/core/maintenance/manual/replacing_nodes.md
index 3f37eb7224d..26f932794f8 100644
--- a/ydb/docs/en/core/maintenance/manual/replacing_nodes.md
+++ b/ydb/docs/en/core/maintenance/manual/replacing_nodes.md
@@ -1 +1,80 @@
-{% include [no-translation](../../_includes/alerts/no-translation.md) %} \ No newline at end of file
+# Replacing a node's FQDN
+
+Sometimes, a node's FQDN changes, but the node itself remains in the system under a different name. Simply changing the node name in the hosts section will not work because `BS_CONTROLLER` internally stores the resource bindings to the `FQDN:IcPort` pairs, where IcPort is the Interconnect port number on which the node operates.
+
+## Replacement procedure
+
+1. Determine the NodeId of the node to be replaced.
+2. Prepare the DefineBox command that describes the cluster resources, in which an element `EnforcedNodeId: <NodeId>` will be added for the resources of the node to be replaced.
+3. Execute this command.
+4. Replace the FQDN in the hosts list in `cluster.yaml`.
+5. Perform a rolling restart.
+6. Remove the EnforcedNodeId field from DefineBox and replace the Fqdn with the new node name.
+7. Execute DefineBox with the new values.
+
+## Example
+
+Suppose a cluster consisting of three nodes:
+
+`config.yaml`:
+
+```yaml
+- host: host1.my.sub.net
+ node_id: 1
+ location: {unit: 12345, data_center: MYDC, rack: r1}
+- host: host2.my.sub.net
+ node_id: 2
+ location: {unit: 23456, data_center: MYDC, rack: r2}
+- host: host3.my.sub.net
+ node_id: 3
+ location: {unit: 34567, data_center: MYDC, rack: r3}
+```
+
+DefineBox looks like this:
+
+```yaml
+DefineBox {
+ BoxId: 1
+ Host { Key { Fqdn: "host1.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+ Host { Key { Fqdn: "host2.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+ Host { Key { Fqdn: "host3.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+}
+```
+
+Suppose we want to rename host1.my.sub.net to host4.my.sub.net. First, we create a DefineBox as follows:
+
+```yaml
+DefineBox {
+ BoxId: 1
+ Host { Key { Fqdn: "host1.my.sub.net" IcPort: 19001 } HostConfigId: 1 EnforcedNodeId: 1 }
+ Host { Key { Fqdn: "host2.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+ Host { Key { Fqdn: "host3.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+}
+```
+
+Then modify `config.yaml`:
+
+```yaml
+- host: host4.my.sub.net
+ node_id: 1
+ location: {unit: 12345, data_center: MYDC, rack: r1}
+- host: host2.my.sub.net
+ node_id: 2
+ location: {unit: 23456, data_center: MYDC, rack: r2}
+- host: host3.my.sub.net
+ node_id: 3
+ location: {unit: 34567, data_center: MYDC, rack: r3}
+```
+
+Next, perform a rolling restart of the cluster.
+
+Finally, perform the second adjusted DefineBox:
+
+```yaml
+DefineBox {
+ BoxId: 1
+ Host { Key { Fqdn: "host4.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+ Host { Key { Fqdn: "host2.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+ Host { Key { Fqdn: "host3.my.sub.net" IcPort: 19001 } HostConfigId: 1 }
+}
+``` \ No newline at end of file