merge

Author: blinkov

ydb/docs/en/core/changelog-server.md

@@ -50,7 +50,7 @@ Release date: December 24, 2024.
 * Added support for [asynchronous replication](./concepts/async-replication), that allows synchronizing data between YDB databases in near real time. It can also be used for data migration between databases with minimal downtime for applications interacting with these databases.
 * Added support for [views](./concepts/datamodel/view), which can be enabled by the cluster administrator using the `enable_views` setting in [dynamic configuration](./maintenance/manual/dynamic-config#updating-dynamic-configuration).
 * Extended [federated query](./concepts/federated_query/) capabilities to support new external data sources: MySQL, Microsoft SQL Server, and Greenplum.
-* Published [documentation](./devops/manual/federated-queries/connector-deployment) on deploying YDB with [federated query](./concepts/federated_query/) functionality (manual setup).
+* Published [documentation](./devops/deployment-options/manual/federated-queries/connector-deployment.md) on deploying YDB with [federated query](./concepts/federated_query/) functionality (manual setup).
 * Added a new launch parameter `FQ_CONNECTOR_ENDPOINT` for YDB Docker containers that specifies an external data source connector address. Added support for TLS encryption for connections to the connector and the ability to expose the connector service port locally on the same host as the dynamic YDB node.
 * Added an [auto-partitioning mode](./concepts/topic#autopartitioning) for topics, where partitions can dynamically split based on load while preserving message read-order and exactly-once guarantees. The mode can be enabled by the cluster administrator using the settings `enable_topic_split_merge` and `enable_pqconfig_transactions_at_scheme_shard` in [dynamic configuration](./maintenance/manual/dynamic-config#updating-dynamic-configuration).
 * Added support for transactions involving [topics](./concepts/topic) and row-based tables, enabling transactional data transfer between tables and topics, or between topics, ensuring no data loss or duplication. Transactions can be enabled by the cluster administrator using the settings `enable_topic_service_tx` and `enable_pqconfig_transactions_at_scheme_shard` in [dynamic configuration](./maintenance/manual/dynamic-config#updating-dynamic-configuration).
@@ -78,7 +78,7 @@ Release date: December 24, 2024.
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1438) a tab with information about [tablets](./concepts/glossary#tablet).
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1289) a tab with details about [distributed storage groups](./concepts/glossary#storage-group).
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1218) a setting to trace all queries and display tracing results.
-* Enhanced the PDisk page with [attributes](https://github.com/ydb-platform/ydb-embedded-ui/pull/1069), disk space consumption details, and a button to initiate [disk decommissioning](./devops/manual/decommissioning).
+* Enhanced the PDisk page with [attributes](https://github.com/ydb-platform/ydb-embedded-ui/pull/1069), disk space consumption details, and a button to initiate [disk decommissioning](./devops/deployment-options/manual/decommissioning.md).
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1313) information about currently running queries.
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1291) a row limit setting for query editor output and a notification when results exceed the limit.
 * [Added](https://github.com/ydb-platform/ydb-embedded-ui/pull/1049) a tab to display top CPU-consuming queries over the last hour.
@@ -123,7 +123,7 @@ Release date: August 20, 2024.
 
 ### Functionality
 
-* Added the ability to set [maintenance task priorities](./devops/manual/maintenance-without-downtime#priority) in the [cluster management system](./concepts/glossary#cms).
+* Added the ability to set [maintenance task priorities](./devops/concepts/maintenance-without-downtime.md#priority) in the [cluster management system](./concepts/glossary.md#cms).
 * Added a setting to enable [stable names](./reference/configuration/#node-broker-config) for cluster nodes within a tenant.
 * Enabled retrieval of nested groups from the [LDAP server](./concepts/auth#ldap-auth-provider), improved host parsing in the [LDAP-configuration](./reference/configuration/#ldap-auth-config), and added an option to disable built-in authentication via login and password.
 * Added support for authenticating [dynamic nodes](./concepts/glossary#dynamic) using SSL-certificates.

ydb/docs/en/core/concepts/federated_query/_includes/connector_deployment.md

@@ -1 +1,5 @@
+<<<<<<< HEAD
 {% if oss == "true" %}Deploy the [connector](../architecture.md#connectors) {% else %}Deploy the connector{% endif %} and {% if oss == true %}[configure](../../../devops/manual/federated-queries/index.md) {% else %}configure{% endif %} the {{ ydb-short-name }} dynamic nodes to interact with it. Additionally, ensure network access from the {{ ydb-short-name }} dynamic nodes to the external data source (at the address specified in the `LOCATION` parameter of the `CREATE EXTERNAL DATA SOURCE` request). If network connection encryption to the external source was enabled in the previous step, the connector will use the system's root certificates (more details on TLS configuration can be found in the [guide](../../../devops/manual/federated-queries/connector-deployment.md) on deploying the connector).
+=======
+{% if oss == "true" %}Deploy the [connector](../architecture.md#connectors) {% else %}Deploy the connector{% endif %} and {% if oss == "true" %}[configure](../../../devops/deployment-options/manual/federated-queries/index.md) {% else %}configure{% endif %} the {{ ydb-short-name }} dynamic nodes to interact with it. Additionally, ensure network access from the {{ ydb-short-name }} dynamic nodes to the external data source (at the address specified in the `LOCATION` parameter of the `CREATE EXTERNAL DATA SOURCE` request). If network connection encryption to the external source was enabled in the previous step, the connector will use the system's root certificates. More details on TLS configuration can be found in the [guide](../../../devops/deployment-options/manual/federated-queries/connector-deployment.md) on deploying the connector.
+>>>>>>> 7e2446459dc ([docs] translate config v2 and other DevOps-related content (#18927))

ydb/docs/en/core/concepts/federated_query/architecture.md

@@ -24,16 +24,26 @@ The functions of connectors include:
 
 Thus, connectors form an abstraction layer that hides the specifics of external data sources from {{ ydb-short-name }}. The concise connector interface makes it easy to expand the list of supported sources with minimal changes to {{ ydb-short-name }}'s code.
 
-Users can deploy [one of the ready-made connectors](../../devops/manual/federated-queries/connector-deployment.md) or write their own implementation in any programming language according to the [gRPC specification](https://github.com/ydb-platform/ydb/tree/main/ydb/library/yql/providers/generic/connector/api).
+Users can deploy [one of the ready-made connectors](../../devops/deployment-options/manual/federated-queries/connector-deployment.md) or write their own implementation in any programming language according to the [gRPC specification](https://github.com/ydb-platform/ydb/tree/main/ydb/library/yql/providers/generic/connector/api/service/protos).
 
 ## List of supported external data sources {#supported-datasources}
 
 | Source | Support |
 |--------|---------|
+<<<<<<< HEAD
 | [ClickHouse](https://clickhouse.com/) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
 | [Greenplum](https://www.greenplum.org/) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
 | [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
 | [MySQL](https://www.mysql.com/) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
 | [PostgreSQL](https://www.postgresql.org/) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
 | [S3](https://aws.amazon.com/ru/s3/) | Built into `ydbd` |
 | [{{ydb-short-name}}](https://ydb.tech/) | Via connector [fq-connector-go](../../devops/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+=======
+| [ClickHouse](https://clickhouse.com/) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+| [Greenplum](https://www.greenplum.org/) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+| [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+| [MySQL](https://www.mysql.com/) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+| [PostgreSQL](https://www.postgresql.org/) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+| [S3](https://aws.amazon.com/s3/) | Built into `ydbd` |
+| [{{ydb-short-name}}](https://ydb.tech/) | Via connector [fq-connector-go](../../devops/deployment-options/manual/federated-queries/connector-deployment.md#fq-connector-go) |
+>>>>>>> 7e2446459dc ([docs] translate config v2 and other DevOps-related content (#18927))

ydb/docs/en/core/contributor/hive.md

@@ -11,7 +11,7 @@ A {{ ydb-short-name }} cluster runs multiple Hives:
 
 When a node registers, it informs Hive of the types of tablets and the number of tablets that can be run on it.
 
-## Resource usage metrics
+## Resource Usage Metrics
 
 Hive evaluates resource usage to evenly distribute tablets across nodes. For each tablet, the usage of four types of resources is tracked:
 
@@ -28,25 +28,25 @@ Resource usage information is used for choosing a node for a tablet. For example
 
 At certain moments, Hive may start an auto-balancing process that moves tablets between nodes to improve load distribution. The situations when autobalancing occurs are listed below. The auto-balancer works iteratively, making decisions about moving tablets one at a time. It selects the most loaded node, chooses a tablet that runs on this node using weighted randomness, and chooses a more suitable node for it. This process is repeated until balance is restored. The way node load is determined depends on the type of balancing. For example, in case of CPU consumption imbalance, CPU usage is used. For uneven distribution of column-oriented tables, the number of tablets is used instead.
 
-### Resource usage imbalance
+### Resource Usage Imbalance
 
 To quantify the balance of resource usage, Hive uses the *Scatter* metric, which is calculated separately for each resource using the following formula:
 
 $$\mathrm{Scatter} = \frac{\mathrm{MaxUsage} - \mathrm{MinUsage}}{\mathrm{MaxUsage}}$$
 
 $\mathrm{MaxUsage}$ and $\mathrm{MinUsage}$ are, respectively, the maximum and minimum usage of a resource across all nodes. To normalize consumption on each node, the number of available resources on the node is used, which may vary between nodes. Under low loads, this metric may fluctuate significantly. To avoid this, when calculating $\mathrm{Scatter}$, it is assumed that resource usage cannot be lower than 30%. The balancer is triggered if $Scatter$ exceeds a threshold.
 
-The maximum value of $Scatter$ across different resources is available as the [sensor](../devops/manual/monitoring.md) `Hive/MAX(BalanceScatter)` in the `tablets` subgroup.
+The maximum value of $Scatter$ across different resources is available as the [sensor](../devops/observability/monitoring.md) `Hive/MAX(BalanceScatter)` in the `tablets` subgroup.
 
-### Node overload
+### Node Overload
 
 Overloaded nodes can negatively affect {{ ydb-short-name }} performance. CPU overload raises latencies, and consuming all memory can cause the node to crash with an out-of-memory error. The balancer is triggered when the load of one node exceeds 90% while the load on another node falls below 70%.
 
-The maximum resource usage on a node is reported by the `Hive/MAX(BalanceUsageMax)` [sensor](../devops/manual/monitoring.md)  in the `tablets` subgroup.
+The maximum resource usage on a node is reported by the `Hive/MAX(BalanceUsageMax)` [sensor](../devops/observability/monitoring.md)  in the `tablets` subgroup.
 
-### Even distribution for a specific object
+### Even Distribution for a Specific Object
 
 For tablets that use the Counter resource, the evenness of tablet distribution for each object (each table) is tracked in the form of the `ObjectImbalance` metric, similar to the $Scatter$ described above. Restarting nodes may break the balance in tablet distribution and trigger balancing.
 
-The maximum value of `ObjectImbalance` across different objects is reported by the `Hive/MAX(BalanceObjectImbalance)` [sensor](../devops/manual/monitoring.md) in the `tablets` subgroup.
+The maximum value of `ObjectImbalance` across different objects is reported by the `Hive/MAX(BalanceObjectImbalance)` [sensor](../devops/observability/monitoring.md) in the `tablets` subgroup.
 

ydb/docs/en/core/contributor/manage-releases.md

@@ -1,13 +1,13 @@
-# Manage {{ ydb-short-name }} releases
+# Manage {{ ydb-short-name }} Releases
 
 There are two products based on the source code from the [{{ ydb-short-name }} repository](https://github.com/ydb-platform/ydb) with independent release cycles:
 
 - [{{ ydb-short-name }} server](#server)
 - [{{ ydb-short-name }} command-line interface (CLI)](#cli)
 
-## {{ ydb-short-name }} server release cycle {#server}
+## {{ ydb-short-name }} Server Release Cycle {#server}
 
-### Release numbers and schedule {#server-versioning}
+### Release Numbers and Schedule {#server-versioning}
 
 {{ ydb-short-name }} server version consists of three numbers separated by dots:
 
@@ -21,13 +21,13 @@ Thus, {{ ydb-short-name }} server major version is a combination of the first tw
 
 ### Compatibility {#server-compatibility}
 
-{{ ydb-short-name }} maintains compatibility between major versions to ensure a cluster can operate while its nodes run two adjacent major versions of the {{ ydb-short-name }} server executable. You may refer the [Updating {{ ydb-short-name }}](../devops/manual/upgrade.md) article to learn more about the cluster upgrade procedure.
+{{ ydb-short-name }} maintains compatibility between major versions to ensure a cluster can operate while its nodes run two adjacent major versions of the {{ ydb-short-name }} server executable. You may refer the [Updating {{ ydb-short-name }}](../devops/deployment-options/manual/update-executable.md) article to learn more about the cluster upgrade procedure.
 
 Given the above compatibility target, major releases go in pairs: odd numbered releases add new functionality switched off by feature flags, and even numbered releases enable that functionality by default.
 
 For instance, release `23.1` comes with the new functionality switched off. It can be incrementally rolled out to a cluster running `22.4`, without downtime. As soon as the whole cluster runs `23.1` nodes, you can manually toggle feature flags to test new functionality and later further upgrade it to `23.2` to fully leverage this new functionality.
 
-### Release branches and tags {#server-branches-tags}
+### Release Branches and Tags {#server-branches-tags}
 
 A release cycle for an odd major release starts by a member of a [YDB Release team](https://github.com/orgs/ydb-platform/teams/release) forking a new branch from the `main` branch. Major release branch name starts with prefix `stable-`, followed with the major version with dots replaced by dashes (for example, `stable-23-1`).
 
@@ -47,15 +47,15 @@ During a testing iteration, code from release branches undergoes an extensive te
 
 Based on a list of uncovered problems, the [{{ ydb-short-name }} Release team](https://github.com/orgs/ydb-platform/teams/release) decides if the current minor release can be promoted to be called "stable", or a new testing iteration must be started over with a new minor release tag. In fact, as soon as a critical problem is discovered during testing, developers fix it in the `main` branch, and backport changes to the release branch right away. So, by the time testing iteration finishes, there will be a new tag and a new testing iteration if there are some new commits on top of the current tag.
 
-### Stable release {#server-stable}
+### Stable Release {#server-stable}
 
 If testing iteration proves the quality of a minor release, the [YDB Release team](https://github.com/orgs/ydb-platform/teams/release) prepares the [release notes](../changelog-server.md), and publishes the YDB server release on both the [GitHub Releases](https://github.com/ydb-platform/ydb/releases) and [Downloads](../downloads/index.md#ydb-server) pages, therefore declaring it as "stable".
 
 {% include [corp_release_stable.md](_includes/corp_release_stable.md) %}
 
-## {{ ydb-short-name }} CLI (Command-Line Interface) release cycle {#cli}
+## {{ ydb-short-name }} CLI (Command-Line Interface) Release Cycle {#cli}
 
-### Release numbers and schedule {#cli-versioning}
+### Release Numbers and Schedule {#cli-versioning}
 
 {{ ydb-short-name }} CLI version consists of three numbers separated by dots:
 
@@ -69,12 +69,12 @@ There's no schedule for the {{ ydb-short-name }} CLI minor releases, a new relea
 
 In general, release cycle for {{ ydb-short-name }} CLI is much simpler and shorter than for the server, producing more frequent releases.
 
-### Release tags {#cli-tags}
+### Release Tags {#cli-tags}
 
 Tags for {{ ydb-short-name }} CLI are assigned on the `main` branch by a member of the [{{ ydb-short-name }} Release team](https://github.com/orgs/ydb-platform/teams/release) after running tests for some revision. To distinguish from the {{ ydb-short-name }} server tags, {{ ydb-short-name }} CLI tags have a `CLI_` prefix before the version number, for example [CLI_2.8.0](https://github.com/ydb-platform/ydb/tree/CLI_2.8.0).
 
 {% include [corp_cli_tags.md](_includes/corp_cli_tags.md) %}
 
-### Stable release {#cli-stable}
+### Stable Release {#cli-stable}
 
 To declare a {{ ydb-short-name }} CLI tag as stable, a member of the [{{ ydb-short-name }} Release team](https://github.com/orgs/ydb-platform/teams/release) prepares the [release notes](../changelog-cli.md), and publishes the release on the [GitHub Releases](https://github.com/ydb-platform/ydb/releases) and [Downloads](../downloads/index.md#ydb-cli) pages.

ydb/docs/en/core/devops/manual/_includes/backup_and_recovery/cli_overlay.md renamed to ydb/docs/en/core/devops/_includes/backup_and_recovery/cli_overlay.md

@@ -0,0 +1,2 @@
+* Backup to files and recovery using {{ ydb-short-name }} CLI.
+* Backup to S3-compatible storage and recovery using {{ ydb-short-name }} CLI.