Управление резервными копиями в Managed Service for PostgreSQL

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию кластер будет восстановлен в тот же каталог, где находится резервная копия. Чтобы восстановить кластер в другом каталоге, укажите идентификатор этого каталога в параметре --folder-id.

Чтобы восстановить кластер из резервной копии:

1. Посмотрите описание команды CLI для восстановления кластера PostgreSQL:

   yc managed-postgresql cluster restore --help
   

2. Получите список доступных резервных копий кластеров PostgreSQL:

   yc managed-postgresql backup list
   

   +--------------------------+---------------------+----------------------+---------------------+
   |              ID          |      CREATED AT     |  SOURCE CLUSTER ID   |      STARTED AT     |
   +--------------------------+---------------------+----------------------+---------------------+
   | c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 |
   | ...                                                                                         |
   +--------------------------+---------------------+----------------------+---------------------+
   

   Время завершения создания резервной копии указано в столбце CREATED AT списка доступных резервных копий в формате yyyy-mm-dd hh:mm:ss (2020-08-10 12:00:00 в примере выше). Вы можете восстановить состояние кластера на любой момент времени, начиная от создания резервной копии.

3. Запросите создание кластера из резервной копии:

   yc managed-postgresql cluster restore \
      --backup-id=<идентификатор_резервной_копии> \
      --time=<время> \
      --name=<имя_кластера> \
      --environment=<окружение> \
      --network-name=<имя_сети> \
      --host zone-id=<зона_доступности>,`
            `subnet-name=<имя_подсети>,`
            `assign-public-ip=<разрешить_публичный_доступ_к_хосту> \
      --resource-preset=<класс_хоста> \
      --disk-size=<размер_хранилища_ГБ> \
      --disk-type=<тип_диска>
   

   Где:

   • --backup-id — идентификатор резервной копии.

   • --time — момент времени, на который нужно восстановить состояние кластера PostgreSQL, в формате yyyy-mm-ddThh:mm:ssZ.

   • --name — имя кластера.

   • --environment — окружение:

     • PRESTABLE — для тестирования. Prestable-окружение аналогично Production-окружению и на него также распространяется SLA, но при этом на нем раньше появляются новые функциональные возможности, улучшения и исправления ошибок. В Prestable-окружении вы можете протестировать совместимость новых версий с вашим приложением.
     • PRODUCTION — для стабильных версий ваших приложений.

   • --network-name — имя сети.

   • --host — параметры хоста:

     • zone-id — зона доступности.

     • subnet-name — имя подсети. Необходимо указывать, если в выбранной зоне доступности создано две или больше подсетей.

     • assign-public-ip — флаг, который указывается, если требуется публичный доступ к хосту: true или false.

   • --resource-preset — класс хоста.

   • --disk-size — размер хранилища в гигабайтах.

   • --disk-type — тип диска:

     • network-hdd;
     • network-ssd;
     • local-ssd;
     • network-ssd-nonreplicated;
     • network-ssd-io-m3.

Используйте Terraform для восстановления:

• Существующего кластера из резервной копии.
• Кластера, созданного и удаленного через Консоль управления, CLI или API.

Для восстановления потребуется идентификатор резервной копии. Получите список доступных резервных копий кластеров PostgreSQL с помощью CLI:

yc managed-postgresql backup list

+--------------------------+---------------------+----------------------+---------------------+
|            ID            |      CREATED AT     |  SOURCE CLUSTER ID   |      STARTED AT     |
+--------------------------+---------------------+----------------------+---------------------+
| c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 |
| ...                                                                                         |
+--------------------------+---------------------+----------------------+---------------------+

resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
  ...
  timeouts {
    create = "1h30m" # Полтора часа
    update = "2h"    # 2 часа
    delete = "30m"   # 30 минут
  }
}

Чтобы восстановить из резервной копии существующий кластер:

1. Создайте конфигурационный файл Terraform для нового кластера.

   При этом не используйте ресурсы баз данных (yandex_mdb_postgresql_database) и пользователей (yandex_mdb_postgresql_user) — они будут восстановлены из резервной копии.

2. Добавьте в конфигурационный файл блок restore:

   resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
     ...
     restore {
       backup_id = "<идентификатор_резервной_копии>"
       time      = "<время>"
     }
   }
   

   Где:

   • backup_id — идентификатор резервной копии.
   • time — момент времени, на который нужно восстановить состояние кластера PostgreSQL, начиная со времени создания выбранной резервной копии. Формат: yyyy-mm-ddThh:mm:ss.

   Примечание

   Если параметр time не указан, кластер будет восстановлен на момент завершения создания резервной копии.

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

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

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

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

   2. Если вас устраивают планируемые изменения, внесите их:

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

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Terraform создаст копию существующего кластера. Базы данных и пользователи будут развернуты из выбранной резервной копии.

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

1. Создайте конфигурационный файл Terraform для нового кластера.

   При этом не используйте ресурсы баз данных (yandex_mdb_postgresql_database) и пользователей (yandex_mdb_postgresql_user) — они будут восстановлены из резервной копии.

2. Добавьте в этот конфигурационный файл блок restore с именем резервной копии, из которой нужно восстановиться:

   resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
     ...
     restore {
         backup_id = "<идентификатор_резервной_копии>"
     }
   }
   

   Где backup-id — идентификатор резервной копии удаленного кластера.

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

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

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

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

   2. Если вас устраивают планируемые изменения, внесите их:

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

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Terraform создаст новый кластер. Базы данных и пользователи будут развернуты из резервной копии.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Создайте файл body.json и добавьте в него следующее содержимое:

   {
     "backupId": "<идентификатор_резервной_копии>",
     "time": "<время>",
     "folderId": "<идентификатор_каталога>",
     "name": "<имя_кластера>",
     "environment": "<окружение>",
     "networkId": "<идентификатор_сети>",
     "configSpec": {
       "version": "<версия_PostgreSQL>",
       "resources": {
         "resourcePresetId": "<класс_хостов>",
         "diskSize": "<размер_хранилища_в_байтах>",
         "diskTypeId": "<тип_диска>"
       }
     },
     "hostSpecs": [
       {
         "zoneId": "<зона_доступности>",
         "subnetId": "<идентификатор_подсети>",
         "assignPublicIp": <разрешить_публичный_доступ_к_хосту>
       }
     ]
   }
   

   Где:

   • backupId — идентификатор резервной копии. Его можно запросить со списком резервных копий.

   • time — момент времени, на который нужно восстановить состояние кластера PostgreSQL, в формате yyyy-mm-ddThh:mm:ssZ.

   • folderId — идентификатор каталога, где будет восстановлен кластер. Идентификатор можно запросить со списком каталогов в облаке.

   • name — имя кластера.

   • environment — окружение:

     • PRESTABLE — для тестирования. Prestable-окружение аналогично Production-окружению и на него также распространяется SLA, но при этом на нем раньше появляются новые функциональные возможности, улучшения и исправления ошибок. В Prestable-окружении вы можете протестировать совместимость новых версий с вашим приложением.
     • PRODUCTION — для стабильных версий ваших приложений.

   • networkId — идентификатор сети.

   • configSpec — настройки кластера:

     • version — версия PostgreSQL.

     • resources — ресурсы кластера:

       • resourcePresetId — класс хостов;
       • diskSize — размер диска в байтах;
       • diskTypeId — тип диска.

   • hostSpecs — настройки хостов кластера в виде массива элементов. Каждый элемент соответствует отдельному хосту и имеет следующую структуру:

     • zoneId — зона доступности;
     • subnetId — идентификатор подсети;
     • assignPublicIp — разрешение на подключение к хосту из интернета: true или false.

3. Воспользуйтесь методом Cluster.Restore и выполните запрос, например, с помощью cURL:

   curl \
     --request POST \
     --header "Authorization: Bearer $IAM_TOKEN" \
     --header "Content-Type: application/json" \
     --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters:restore' \
     --data "@body.json"
   

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Создайте файл body.json и добавьте в него следующее содержимое:

   {
     "backup_id": "<идентификатор_резервной_копии>",
     "time": "<время>",
     "folder_id": "<идентификатор_каталога>",
     "name": "<имя_кластера>",
     "environment": "<окружение>",
     "network_id": "<идентификатор_сети>",
     "config_spec": {
       "version": "<версия_PostgreSQL>",
       "resources": {
         "resource_preset_id": "<класс_хостов>",
         "disk_size": "<размер_хранилища_в_байтах>",
         "disk_type_id": "<тип_диска>"
       }
     },
     "host_specs": [
       {
         "zone_id": "<зона_доступности>",
         "subnet_id": "<идентификатор_подсети>",
         "assign_public_ip": <разрешить_публичный_доступ_к_хосту>
       }
     ]
   }
   

   Где:

   • backup_id — идентификатор резервной копии. Его можно запросить со списком резервных копий.

   • time — момент времени, на который нужно восстановить состояние кластера PostgreSQL, в формате yyyy-mm-ddThh:mm:ssZ.

   • folder_id — идентификатор каталога, где будет восстановлен кластер. Идентификатор можно запросить со списком каталогов в облаке.

   • name — имя кластера.

   • environment — окружение:

     • PRESTABLE — для тестирования. Prestable-окружение аналогично Production-окружению и на него также распространяется SLA, но при этом на нем раньше появляются новые функциональные возможности, улучшения и исправления ошибок. В Prestable-окружении вы можете протестировать совместимость новых версий с вашим приложением.
     • PRODUCTION — для стабильных версий ваших приложений.

   • network_id — идентификатор сети.

   • config_spec — настройки кластера:

     • version — версия PostgreSQL.

     • resources — ресурсы кластера:

       • resource_preset_id — класс хостов;
       • disk_size — размер диска в байтах;
       • disk_type_id — тип диска.

   • host_specs — настройки хостов кластера в виде массива элементов. Каждый элемент соответствует отдельному хосту и имеет следующую структуру:

     • zone_id — зона доступности;
     • subnet_id — идентификатор подсети;
     • assign_public_ip — разрешение на подключение к хосту из интернета: true или false.

4. Воспользуйтесь вызовом ClusterService.Restore и выполните запрос, например, с помощью gRPCurl:

   grpcurl \
     -format json \
     -import-path ~/cloudapi/ \
     -import-path ~/cloudapi/third_party/googleapis/ \
     -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
     -rpc-header "Authorization: Bearer $IAM_TOKEN" \
     -d @ \
     mdb.api.cloud.yandex.net:443 \
     yandex.cloud.mdb.postgresql.v1.ClusterService.Restore \
     < body.json
   

5. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id. Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

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

1. Посмотрите описание команды CLI для создания резервной копии PostgreSQL:

   yc managed-postgresql cluster backup --help
   

2. Запросите создание резервной копии, указав имя или идентификатор кластера:

   yc managed-postgresql cluster backup my-pg-cluster
   

   Имя и идентификатор кластера можно получить со списком кластеров.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Воспользуйтесь методом Cluster.Backup и выполните запрос, например, с помощью cURL:

   curl \
     --request POST \
     --header "Authorization: Bearer $IAM_TOKEN" \
     --header "Content-Type: application/json" \
     --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters/<идентификатор_кластера>:backup'
   

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Воспользуйтесь вызовом ClusterService.Backup и выполните запрос, например, с помощью gRPCurl:

   grpcurl \
     -format json \
     -import-path ~/cloudapi/ \
     -import-path ~/cloudapi/third_party/googleapis/ \
     -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
     -rpc-header "Authorization: Bearer $IAM_TOKEN" \
     -d '{
           "cluster_id": "<идентификатор_кластера>"
         }' \
     mdb.api.cloud.yandex.net:443 \
     yandex.cloud.mdb.postgresql.v1.ClusterService.Backup
   

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id. Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

Чтобы получить список резервных копий кластеров PostgreSQL, доступных в каталоге по умолчанию, выполните команду:

yc managed-postgresql backup list

+--------------------------+---------------------+----------------------+---------------------+
|            ID            |      CREATED AT     |  SOURCE CLUSTER ID   |      STARTED AT     |
+--------------------------+---------------------+----------------------+---------------------+
| c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 |
| c9qpm90p3pcg********:... | 2020-08-09 22:01:04 | c9qpm90p3pcg******** | 2020-08-09 21:30:00 |
+--------------------------+---------------------+----------------------+---------------------+

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Чтобы получить список резервных копий кластера:

   1. Воспользуйтесь методом Cluster.ListBackups и выполните запрос, например, с помощью cURL:

      curl \
         --request GET \
         --header "Authorization: Bearer $IAM_TOKEN" \
         --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters/<идентификатор_кластера>/backups'
      

      Идентификатор кластера можно запросить со списком кластеров в каталоге.

   2. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

3. Чтобы получить список резервных копий всех кластеров в каталоге:

   1. Воспользуйтесь методом Backup.List и выполните запрос, например, с помощью cURL:

      curl \
         --request GET \
         --header "Authorization: Bearer $IAM_TOKEN" \
         --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/backups' \
         --url-query folderId=<идентификатор_каталога>
      

      Идентификатор каталога можно запросить со списком каталогов в облаке.

   2. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Чтобы получить список резервных копий кластера:

   1. Воспользуйтесь вызовом ClusterService.ListBackups и выполните запрос, например, с помощью gRPCurl:

      grpcurl \
        -format json \
        -import-path ~/cloudapi/ \
        -import-path ~/cloudapi/third_party/googleapis/ \
        -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
        -rpc-header "Authorization: Bearer $IAM_TOKEN" \
        -d '{
              "cluster_id": "<идентификатор_кластера>"
            }' \
        mdb.api.cloud.yandex.net:443 \
        yandex.cloud.mdb.postgresql.v1.ClusterService.ListBackups
      

      Идентификатор кластера можно запросить со списком кластеров в каталоге.

   2. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

4. Чтобы получить список резервных копий всех кластеров в каталоге:

   1. Воспользуйтесь вызовом BackupService.List и выполните запрос, например, с помощью gRPCurl:

      grpcurl \
        -format json \
        -import-path ~/cloudapi/ \
        -import-path ~/cloudapi/third_party/googleapis/ \
        -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/backup_service.proto \
        -rpc-header "Authorization: Bearer $IAM_TOKEN" \
        -d '{
              "folder_id": "<идентификатор_каталога>"
            }' \
        mdb.api.cloud.yandex.net:443 \
        yandex.cloud.mdb.postgresql.v1.BackupService.List
      

      Идентификатор каталога можно запросить со списком каталогов в облаке.

   2. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id. Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

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

yc managed-postgresql backup get <идентификатор_резервной_копии>

Идентификатор резервной копии можно получить со списком резервных копий.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Воспользуйтесь методом Backup.Get и выполните запрос, например, с помощью cURL:

   curl \
      --request GET \
      --header "Authorization: Bearer $IAM_TOKEN" \
      --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/backups/<идентификатор_резервной_копии>'
   

   Идентификатор резервной копии можно запросить со списком резервных копий.

3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Воспользуйтесь вызовом BackupService.Get и выполните запрос, например, с помощью gRPCurl:

   grpcurl \
     -format json \
     -import-path ~/cloudapi/ \
     -import-path ~/cloudapi/third_party/googleapis/ \
     -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/backup_service.proto \
     -rpc-header "Authorization: Bearer $IAM_TOKEN" \
     -d '{
           "backup_id": "<идентификатор_резервной_копии>"
         }' \
     mdb.api.cloud.yandex.net:443 \
     yandex.cloud.mdb.postgresql.v1.BackupService.Get
   

   Идентификатор резервной копии можно запросить со списком резервных копий.

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Чтобы задать время начала резервного копирования, используйте параметр --backup-window-start. Время задается в формате ЧЧ:ММ:СС.

yc managed-postgresql cluster create \
   --cluster-name <имя_кластера> \
   --environment <окружение> \
   --network-name <имя_сети> \
   --host zone-id=<зона_доступности>,subnet-id=<идентификатор_подсети> \
   --resource-preset <класс_хоста> \
   --user name=<имя_пользователя>,password=<пароль_пользователя> \
   --database name=<имя_БД>,owner=<имя_владельца_БД> \
   --disk-size <размер_хранилища_ГБ>
   --backup-window-start 10:00:00

Где environment — окружение: prestable или production.

Изменить время начала резервного копирования в существующем кластере можно с помощью команды update:

yc managed-postgresql cluster update \
   --cluster-name <имя_кластера> \
   --backup-window-start 11:25:00

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание кластера.

   Полный список доступных для изменения полей конфигурации кластера Managed Service for PostgreSQL см. в документации провайдера Terraform.

2. Добавьте к описанию кластера Managed Service for PostgreSQL блок backup_window_start в секции config:

   resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
     ...
     config {
       ...
       backup_window_start {
         hours   = <час>
         minutes = <минута>
       }
       ...
     }
     ...
   

   Где:

   • hours — час начала резервного копирования (UTC).
   • minutes — минута начала резервного копирования (UTC).

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

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

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

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

   2. Если вас устраивают планируемые изменения, внесите их:

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

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

   Ограничения по времени

   Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for PostgreSQL:

   • создание, в том числе путем восстановления из резервной копии, — 30 минут;
   • изменение — 60 минут;
   • удаление — 15 минут.

   Операции, длящиеся дольше указанного времени, прерываются.

   Как изменить эти ограничения?

   Добавьте к описанию кластера блок timeouts, например:

   resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
     ...
     timeouts {
       create = "1h30m" # Полтора часа
       update = "2h"    # 2 часа
       delete = "30m"   # 30 минут
     }
   }
   

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Воспользуйтесь методом Cluster.Update и выполните запрос, например, с помощью cURL:

   Важно

   Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре updateMask (одной строкой через запятую).

   curl \
     --request PATCH \
     --header "Authorization: Bearer $IAM_TOKEN" \
     --header "Content-Type: application/json" \
     --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters/<идентификатор_кластера>' \
     --data '{
               "updateMask": "configSpec.backupWindowStart",
               "configSpec": {
                 "backupWindowStart": {
                   "hours": "<часы>",
                   "minutes": "<минуты>",
                   "seconds": "<секунды>",
                   "nanos": "<наносекунды>"
                 }
               }
             }'
   

   Где:

   • updateMask — перечень изменяемых параметров в одну строку через запятую.

     В данном случае передается только один параметр.

   • configSpec.backupWindowStart — настройки окна резервного копирования.

     В параметре укажите время, когда начинать резервное копирование. Возможные значения параметров:

     • hours — от 0 до 23 часов;
     • minutes — от 0 до 59 минут;
     • seconds — от 0 до 59 секунд;
     • nanos — от 0 до 999999999 наносекунд.

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Воспользуйтесь вызовом ClusterService.Update и выполните запрос, например, с помощью gRPCurl:

   Важно

   Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре update_mask (в виде массива строк paths[]).

   Формат перечисления настроек

   "update_mask": {
       "paths": [
           "<настройка_1>",
           "<настройка_2>",
           ...
           "<настройка_N>"
       ]
   }
   

   grpcurl \
     -format json \
     -import-path ~/cloudapi/ \
     -import-path ~/cloudapi/third_party/googleapis/ \
     -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
     -rpc-header "Authorization: Bearer $IAM_TOKEN" \
     -d '{
           "cluster_id": "<идентификатор_кластера>",
           "update_mask": {
             "paths": [
               "config_spec.backup_window_start"
             ]
           },
           "config_spec": {
             "backup_window_start": {
               "hours": "<часы>",
               "minutes": "<минуты>",
               "seconds": "<секунды>",
               "nanos": "<наносекунды>"
             }
           }
         }' \
     mdb.api.cloud.yandex.net:443 \
     yandex.cloud.mdb.postgresql.v1.ClusterService.Update
   

   Где:

   • update_mask — перечень изменяемых параметров в виде массива строк paths[].

     В данном случае передается только один параметр.

   • config_spec.backup_window_start — настройки окна резервного копирования.

     В параметре укажите время, когда начинать резервное копирование. Возможные значения параметров:

     • hours — от 0 до 23 часов;
     • minutes — от 0 до 59 минут;
     • seconds — от 0 до 59 секунд;
     • nanos — от 0 до 999999999 наносекунд.

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id. Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

Чтобы задать срок хранения автоматических резервных копий, передайте нужное значение в аргументе --backup-retain-period-days команды изменения кластера:

yc managed-postgresql cluster update <имя_или_идентификатор_кластера> \
   --backup-retain-period-days=<срок_хранения_в_днях>

Допустимые значения: от 7 до 60. Значение по умолчанию — 7.

Идентификатор и имя кластера можно запросить со списком кластеров в каталоге.

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание кластера.

   Полный список доступных для изменения полей конфигурации кластера Managed Service for PostgreSQL см. в документации провайдера Terraform.

2. Добавьте к описанию кластера Managed Service for PostgreSQL блок backup_retain_period_days в секции config:

     resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
       ...
       config {
         ...
         backup_retain_period_days = <срок_хранения_в_днях>
         }
         ...
       }
       ...
   

   Где backup_retain_period_days — срок хранения автоматических резервных копий.

   Допустимые значения: от 7 до 60. Значение по умолчанию — 7.

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

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

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

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

   2. Если вас устраивают планируемые изменения, внесите их:

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

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

   Ограничения по времени

   Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for PostgreSQL:

   • создание, в том числе путем восстановления из резервной копии, — 30 минут;
   • изменение — 60 минут;
   • удаление — 15 минут.

   Операции, длящиеся дольше указанного времени, прерываются.

   Как изменить эти ограничения?

   Добавьте к описанию кластера блок timeouts, например:

   resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
     ...
     timeouts {
       create = "1h30m" # Полтора часа
       update = "2h"    # 2 часа
       delete = "30m"   # 30 минут
     }
   }
   

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Воспользуйтесь методом Cluster.Update и выполните запрос, например, с помощью cURL:

   Важно

   Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре updateMask (одной строкой через запятую).

   curl \
     --request PATCH \
     --header "Authorization: Bearer $IAM_TOKEN" \
     --header "Content-Type: application/json" \
     --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters/<идентификатор_кластера>' \
     --data '{
               "updateMask": "configSpec.backupRetainPeriodDays",
               "configSpec": {
                 "backupRetainPeriodDays": <срок_хранения_в_днях>
               }
             }'
   

   Где:

   • updateMask — перечень изменяемых параметров в одну строку через запятую.

     В данном случае передается только один параметр.

   • configSpec.backupRetainPeriodDays — срок хранения автоматических резервных копий.

     Допустимые значения — от 7 до 60. Значение по умолчанию — 7.

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Воспользуйтесь вызовом ClusterService.Update и выполните запрос, например, с помощью gRPCurl:

   Важно

   Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре update_mask (в виде массива строк paths[]).

   Формат перечисления настроек

   "update_mask": {
       "paths": [
           "<настройка_1>",
           "<настройка_2>",
           ...
           "<настройка_N>"
       ]
   }
   

   grpcurl \
   -format json \
   -import-path ~/cloudapi/ \
   -import-path ~/cloudapi/third_party/googleapis/ \
   -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
   -rpc-header "Authorization: Bearer $IAM_TOKEN" \
   -d '{
           "cluster_id": "<идентификатор_кластера>",
           "update_mask": {
           "paths": [
               "config_spec.backup_retain_period_days"
           ]
           },
           "config_spec": {
           "backup_retain_period_days": <срок_хранения_в_днях>
           }
       }' \
   mdb.api.cloud.yandex.net:443 \
   yandex.cloud.mdb.postgresql.v1.ClusterService.Update
   

   Где:

   • update_mask — перечень изменяемых параметров в виде массива строк paths[].

     В данном случае передается только один параметр.

   • config_spec.backup_retain_period_days — срок хранения автоматических резервных копий.

     Допустимые значения — от 7 до 60. Значение по умолчанию — 7.

   Идентификатор кластера можно запросить со списком кластеров в каталоге.

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

Если у вас еще нет интерфейса командной строки Yandex Cloud (CLI), установите и инициализируйте его.

По умолчанию используется каталог, указанный при создании профиля CLI. Чтобы изменить каталог по умолчанию, используйте команду yc config set folder-id <идентификатор_каталога>. Также для любой команды вы можете указать другой каталог с помощью параметров --folder-name или --folder-id. Если вы обращаетесь к ресурсу по имени, поиск будет выполнен в каталоге по умолчанию. Если вы обращаетесь к ресурсу по идентификатору, поиск будет выполнен глобально — во всех каталогах с учетом прав доступа.

Чтобы удалить резервную копию:

1. Посмотрите описание команды CLI для удаления резервной копии PostgreSQL:

   yc managed-postgresql backup delete --help
   

2. Запросите удаление резервной копии, указав ее идентификатор:

   yc managed-postgresql backup delete <идентификатор_резервной_копии>
   

Идентификатор резервной копии можно получить со списком резервных копий.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Воспользуйтесь методом Backup.Delete и выполните запрос, например, с помощью cURL:

   curl \
     --request DELETE \
     --header "Authorization: Bearer $IAM_TOKEN" \
     --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/backups/<идентификатор_резервной_копии>'
   

   Идентификатор резервной копии можно запросить со списком резервных копий.

3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

   export IAM_TOKEN="<IAM-токен>"
   

2. Клонируйте репозиторий cloudapi:

   cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
   

   Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

3. Воспользуйтесь вызовом BackupService.Delete и выполните запрос, например, с помощью gRPCurl:

   grpcurl \
     -format json \
     -import-path ~/cloudapi/ \
     -import-path ~/cloudapi/third_party/googleapis/ \
     -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/backup_service.proto \
     -rpc-header "Authorization: Bearer $IAM_TOKEN" \
     -d '{
           "backup_id": "<идентификатор_резервной_копии>"
         }' \
     mdb.api.cloud.yandex.net:443 \
     yandex.cloud.mdb.postgresql.v1.BackupService.Delete
   

   Идентификатор резервной копии можно запросить со списком резервных копий.

4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.