[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for ClickHouse®](../index.md) > Справочник Terraform > Миграция кластера с v1 на v2

# Миграция кластера с v1 на v2

Перед началом миграции рекомендуем ознакомиться с [изменениями](../concepts/migration-v1-v2.md).

Чтобы выполнить миграцию кластера с [ресурса v1](../../terraform/resources/mdb_clickhouse_cluster.md) (`yandex_mdb_clickhouse_cluster`) на [ресурс v2](../../terraform/resources/mdb_clickhouse_cluster_v2.md) (`yandex_mdb_clickhouse_cluster_v2`):

1. [Обновите конфигурацию Terraform](#update-config).
1. [Сохраните идентификатор кластера](#get-id).
1. [Удалите старый ресурс из state](#remove-old-resource).
1. [Импортируйте существующий ресурс в новый](#import-resource).
1. [(Опционально) Импортируйте базы данных и пользователей](#import-db-users).
1. [Проверьте планируемые изменения](#tf-plan).
1. [Примените изменения](#tf-apply).


## Обновите конфигурацию Terraform {#update-config}

1. Внесите все синтаксические изменения, которые указаны в таблице:

    | v1 (блочный синтаксис)                                   | v2 (синтаксис присваивания)               |
    | --- | --- |
    | `clickhouse { }`                                         | `clickhouse = { }`                        |
    | `zookeeper { }`                                          | `zookeeper = { }`                         |
    | `access { }`                                             | `access = { }`                            |
    | `cloud_storage { }`                                      | `cloud_storage = { }`                     |
    | `backup_window_start { }`                                | `backup_window_start = { }`               |
    | `clickhouse.config.kafka { }`                            | `kafka = { }` (внутри `config`)           |
    | `clickhouse.config.rabbitmq { }`                         | `rabbitmq = { }` (внутри `config`)        |
    | `clickhouse.config.compression { }` (повторяющийся блок) | `compression = [{ method = "LZ4", ... }]` |
    | `host { }` (повторяющийся блок)                          | `hosts = { "key" = { } }`                 |
    | `shard { }` (повторяющийся блок)                         | `shards = { "shard1" = { } }`             |

1. Задайте ключи для хостов.


## Сохраните идентификатор кластера {#get-id}

1. Выполните команду:

    ```sh
    terraform state show yandex_mdb_clickhouse_cluster.main
    ```

1. Скопируйте значение `id` из вывода, оно понадобится далее.


## Удалите старый ресурс из state {#remove-old-resource}

Выполните команду:

```sh
terraform state rm yandex_mdb_clickhouse_cluster.main
```


## Импортируйте существующий ресурс в новый {#import-resource}

Выполните команду:

```sh
terraform import yandex_mdb_clickhouse_cluster_v2.main <идентификатор_кластера>
```

В команде используйте значение `id`, которое вы получили ранее.

После импорта ключами хостов в `state` станут их FQDN, например `"rc1a-abc.mdb.yandexcloud.kz"`.


## (Опционально) Импортируйте базы данных и пользователей {#import-db-users}

Если `database {}` или `user {}` раньше были частью ресурса кластера, а теперь представлены отдельными ресурсами, импортируйте их:

```sh
terraform import 'yandex_mdb_clickhouse_database.mydb' "<идентификатор_кластера>:<имя_БД>"
terraform import 'yandex_mdb_clickhouse_user.myuser'   "<идентификатор_кластера>:<имя_пользователя>"
```


## Проверьте планируемые изменения {#tf-plan}

Выполните команду:

```sh
terraform plan
```

В терминале отобразится список ресурсов с параметрами. Это проверочный этап: ресурсы не будут созданы. Если в конфигурации есть ошибки, Terraform на них укажет.

В `plan` все хосты могут отображаться как `+` и `-`. Хотя это и выглядит настораживающе, применение изменений безопасно для совпадающих хостов.

Провайдер выполняет сопоставление хостов в три этапа:

1. Ключ совпадает в `plan` и `state` — хост сохраняется без изменений, никаких действий не требуется.
1. Полное соответствие по `zone`, `subnet_id`, `type`, `shard_name`, `assign_public_ip` — ключ в `state` переименовывается в ключ из `plan`, сам хост не затрагивается.
1. Частичное совпадение по `zone`, `FQDN`, `shard_name`, `subnet_id` — ключ в `state` переименовывается в ключ из `plan`, при этом может потребоваться обновление, например `assign_public_ip`.

Для ключей хостов в `plan` используются короткие ключи, например `"c1"`, `"k1"`. При совпадении `zone`, `subnet`, `type` и `shard` запустится второй этап сопоставления: ключи будут переименованы без фактических изменений хостов.

{% note warning %}

Перед выполнением `terraform apply` убедитесь, что для каждого хоста, который отображается как `+` и `-`, значения `zone`, `subnet_id`, `type`, `shard_name` и `assign_public_ip` совпадают. Изменение любого из этих полей может привести к пересозданию хоста.

{% endnote %}


## Примените изменения {#tf-apply}

1. Чтобы создать ресурсы, выполните команду:

    ```bash
    terraform apply
    ```

1. Подтвердите создание ресурсов: введите в терминал слово `yes` и нажмите **Enter**.

    Terraform создаст все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в [консоли управления](https://kz.console.yandex.cloud).

В случае возникновения ошибок ознакомьтесь с разделом [Ошибки при миграции](../concepts/migration-v1-v2.md#errors).


#### Полезные ссылки {#see-also}

* [Изменения в кластере v2](../concepts/migration-v1-v2.md)