Миграция базы данных из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
Примечание
Миграция данных в сторонний кластер PostgreSQL описана в разделе Миграция базы данных из Managed Service for PostgreSQL.
Перенести данные из стороннего кластера-источника в кластер-приемник Managed Service for PostgreSQL можно тремя способами:
-
Перенос данных с использованием сервиса Yandex Data Transfer.
Этот способ позволяет:
- обойтись без создания промежуточной виртуальной машины или разрешения доступа к вашему кластеру-приемнику Managed Service for PostgreSQL из интернета;
- перенести базу целиком без остановки обслуживания пользователей;
- мигрировать со старых версий PostgreSQL на более новые, в том числе обновить кластер с версии PostgreSQL 15 до версии 16.
Чтобы использовать этот способ, разрешите подключение к кластеру-источнику из интернета.
Подробнее см. в разделе Какие задачи решает сервис Yandex Data Transfer.
-
Перенос данных с помощью логической репликации.
Логическая репликация
использует механизм подписки (subscriptions) . Это позволяет перенести данные в кластер-приемник с минимальным временем простоя.Используйте этот способ только в том случае, если перенос данных с помощью Yandex Data Transfer по каким-либо причинам невозможен.
-
Перенос данных через создание и восстановление логического дампа.
Логический дамп — файл с набором команд, последовательное выполнение которых позволяет восстановить состояние базы данных. Он создается с помощью утилиты
pg_dump
. Чтобы обеспечить полноту логического дампа, перед его созданием кластер-источник следует перевести в режимтолько чтение
.Используйте этот способ только в том случае, если перенос данных с помощью любого из предыдущих способов по каким-либо причинам невозможен.
Перенос данных с использованием сервиса Yandex Data Transfer
-
Подготовьте инфраструктуру:
ВручнуюTerraform-
Создайте кластер-приемник Managed Service for PostgreSQL любой подходящей конфигурации. При этом:
- Версия PostgreSQL должна быть не ниже, чем в кластере-источнике. Миграция с понижением версии PostgreSQL невозможна.
- При создании кластера укажите то же имя базы данных, что и в кластере-источнике.
- Включите те же расширения PostgreSQL, что и в кластере-источнике.
-
Создайте эндпоинт для источника со следующими параметрами:
- Тип базы данных —
PostgreSQL
. - Параметры эндпоинта → Настройки подключения —
Пользовательская инсталляция
.
Укажите параметры подключения к кластеру-источнику.
- Тип базы данных —
-
Создайте эндпоинт для приемника со следующими параметрами:
- Тип базы данных —
PostgreSQL
. - Параметры эндпоинта → Настройки подключения —
Кластер Managed Service for PostgreSQL
.
Укажите идентификатор кластера-приемника.
- Тип базы данных —
-
Создайте трансфер типа Копирование и репликация, использующий созданные эндпоинты.
-
Важно
Избегайте любых изменений в схеме данных в кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.
-
Если у вас еще нет Terraform, установите его.
-
Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.
-
Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.
-
Скачайте в ту же рабочую директорию файл конфигурации data-transfer-pgsql-mpg.tf
.В этом файле описаны:
- сеть;
- подсеть;
- группа безопасности и правило, необходимое для подключения к кластеру;
- кластер-приемник Managed Service for PostgreSQL;
- эндпоинт для источника;
- эндпоинт для приемника;
- трансфер.
-
Укажите в файле
data-transfer-pgsql-mpg.tf
:-
pg-extensions
– список расширений PostgreSQL в кластере-источнике; -
параметры кластера-приемника, которые используются и как параметры эндпоинта-приемника:
target_pgsql_version
— версия PostgreSQL, она должна быть не ниже, чем в кластере-источнике;target_user
иtarget_password
— имя и пароль пользователя-владельца базы данных.
-
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Создайте необходимую инфраструктуру:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления
.Трансфер активируется автоматически после создания.
-
-
-
Дождитесь перехода трансфера в статус Реплицируется.
-
Переведите кластер-источник в режим
только чтение
. -
На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum data transfer delay. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
-
Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.
Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.
-
Переключите нагрузку на кластер-приемник.
-
Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:
Ресурсы созданы вручнуюРесурсы созданы с помощью Terraform- Удалите кластер Managed Service for PostgreSQL.
- Удалите остановленный трансфер.
- Удалите эндпоинты для источника и приемника.
-
В терминале перейдите в директорию с планом инфраструктуры.
-
Удалите конфигурационный файл
data-transfer-pgsql-mpg.tf
. -
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
Все ресурсы, которые были описаны в конфигурационном файле
data-transfer-pgsql-mpg.tf
, будут удалены. -
Перенос данных с помощью логической репликации
Логическая репликация поддерживается PostgreSQL с версии 10. Кроме миграции данных между одинаковыми версиями PostgreSQL, логическая репликация позволяет мигрировать на более новые версии PostgreSQL.
В кластерах Managed Service for PostgreSQL подписки может использовать владелец базы данных (пользователь, созданный одновременно с кластером) и пользователи с ролью mdb_admin
для этого кластера.
Этапы миграции:
- Настройте кластер-источник.
- Экспортируйте схему БД в кластере-источнике.
- Восстановите схему БД в кластере-приемнике.
- Создайте публикацию и подписку PostgreSQL.
- Перенесите PostgreSQL-sequence после репликации.
- Отключите репликацию и перенесите нагрузку.
Если созданные ресурсы вам больше не нужны, удалите их.
Перед началом работы
Создайте необходимые ресурсы:
Создайте кластер-приемник Managed Service for PostgreSQL любой подходящей конфигурации. При этом:
- Версия PostgreSQL должна быть не ниже, чем в кластере-источнике. Миграция с понижением версии PostgreSQL невозможна.
- При создании кластера укажите то же имя базы данных, что и в кластере-источнике.
- Включите те же расширения PostgreSQL, что и в кластере-источнике.
-
Если у вас еще нет Terraform, установите его.
-
Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.
-
Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.
-
Скачайте в ту же рабочую директорию файл конфигурации data-migration-pgsql-mpg.tf
.В этом файле описаны:
- сеть;
- подсеть;
- группа безопасности и правило, необходимое для подключения к кластеру;
- кластер Managed Service for PostgreSQL с публичным доступом из интернета.
-
Укажите в файле
data-migration-pgsql-mpg.tf
:-
source_db_name
— имя базы данных; -
pg-extensions
– список расширений PostgreSQL в кластере-источнике; -
параметры кластера-приемника:
target_pgsql_version
— версия PostgreSQL, она должна быть не ниже, чем в кластере-источнике;target_user
иtarget_password
— имя и пароль пользователя-владельца базы данных.
-
-
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Создайте необходимую инфраструктуру:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления
. -
Настройте кластер-источник
-
Укажите нужные настройки SSL и WAL в файле
postgresql.conf
. В ОС Debian и Ubuntu путь к этому файлу по умолчанию —/etc/postgresql/<версия_PostgreSQL>/main/postgresql.conf
.-
Для миграции данных рекомендуется использовать SSL: это поможет не только шифровать данные, но и сжимать их. Подробнее в разделах документации PostgreSQL, SSL Support
и Database Connection Control Functions .Чтобы включить использование SSL, задайте нужное значение в конфигурации:
ssl = on # on, off
-
Измените уровень логирования для Write Ahead Log (WAL)
, чтобы добавить в него информацию, необходимую для логической репликации. Для этого установите значениеlogical
для настройки wal_level .Настройку можно изменить в файле
postgresql.conf
. Найдите строку с настройкойwal_level
, раскомментируйте ее при необходимости и установите значениеlogical
:wal_level = logical # minimal, replica, or logical
-
-
Настройте аутентификацию хостов в кластере-источнике. Для этого нужно внести хосты кластера в Yandex Cloud в файл
pg_hba.conf
(на дистрибутивах Debian и Ubuntu по умолчанию расположен по пути/etc/postgresql/<версия_PostgreSQL>/main/pg_hba.conf
).Добавьте строки для разрешения подключения к базе данных с указанных хостов:
-
Если вы используете SSL:
hostssl all all <адрес_хоста> md5 hostssl replication all <адрес_хоста> md5
-
Если вы не используете SSL:
host all all <адрес_хоста> md5 host replication all <адрес_хоста> md5
-
-
Если в кластере-источнике работает файрвол, разрешите входящие соединения с хостов кластера Managed Service for PostgreSQL. Например, для Ubuntu 18:
sudo ufw allow from <адрес_хоста_кластера-приемника> to any port <порт>
-
Перезапустите сервис PostgreSQL, чтобы применить все сделанные настройки:
sudo systemctl restart postgresql
-
Проверьте статус сервиса PostgreSQL после перезапуска:
sudo systemctl status postgresql
Экспортируйте схему БД в кластере-источнике
С помощью утилиты pg_dump
создайте файл со схемой БД, которую нужно будет применить в кластере-приемнике.
pg_dump -h <IP-адрес_или_FQDN_хоста-мастера_кластера-источника> \
-U <имя_пользователя> \
-p <порт> \
--schema-only \
--no-privileges \
--no-subscriptions \
-d <имя_БД> \
-Fd -f /tmp/db_dump
В этой команде при экспорте исключаются все данные, связанные с привилегиями и ролями, чтобы не возникало конфликтов с настройками БД в Yandex Cloud. Если вашей БД нужны дополнительные пользователи, создайте их.
Восстановите схему БД в кластере-приемнике
С помощью утилиты pg_restore
восстановите схему БД в кластере-приемнике:
pg_restore -h <IP-адрес_или_FQDN_хоста-мастера_кластера-приемника> \
-U <имя_пользователя> \
-p 6432 \
-Fd -v \
--single-transaction \
-s --no-privileges \
-d <имя_БД> /tmp/db_dump
Создайте публикацию и подписку
Для работы логической репликации необходимо создать публикацию (группу логически реплицируемых таблиц) в кластере-источнике и подписку (описание соединения с другой базой) в кластере-приемнике.
-
В кластере-источнике создайте публикацию для всех таблиц базы данных. При переносе нескольких баз для каждой из них нужно создать отдельную публикацию.
Примечание
Для создания публикации на все таблицы потребуются права суперпользователя, а для переноса выбранных таблиц — нет. Более подробно о создании публикации см. в документации PostgreSQL
.Запрос:
CREATE PUBLICATION p_data_migration FOR ALL TABLES;
-
На хосте кластера Managed Service for PostgreSQL создайте подписку со строкой подключения к публикации. Более подробно о создании подписок см. в документации PostgreSQL
.Запрос с включенным SSL:
CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес_кластера-источника> port=<порт> user=<имя_пользователя> sslmode=verify-full dbname=<имя_БД>' PUBLICATION p_data_migration;
Без SSL:
CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес_кластера-источника> port=<порт> user=<имя_пользователя> sslmode=disable dbname=<имя_БД>' PUBLICATION p_data_migration;
-
Чтобы получить статус репликации, обратитесь к каталогам
pg_subscription_rel
. Общий статус репликации в кластере-приемнике можно получить черезpg_stat_subscription
, в кластере-источнике — черезpg_stat_replication
.SELECT * FROM pg_subscription_rel;
Прежде всего обратите внимание на поле
srsubstate
. Значениеr
в нем означает, что синхронизация завершилась, и базы готовы к репликации.
Перенесите PostgreSQL-sequences после репликации
Чтобы завершить синхронизацию кластера-источника и кластера-приемника:
-
Переведите кластер-источник в режим
только чтение
. -
Создайте дамп с PostgreSQL-sequences в кластере-источнике:
pg_dump -h <IP-адрес_или_FQDN_хоста-мастера_кластера-источника> \ -U <имя_пользователя> \ -p <порт> \ -d <имя_БД> \ --data-only -t '*.*_seq' > /tmp/seq-data.sql
Обратите внимание на используемый паттерн
*.*_seq
. Если в переносимой базе есть не соответствующие ему sequences, то для их выгрузки укажите другой паттерн.Подробнее о паттернах см. в документации PostgreSQL
. -
Восстановите дамп с sequences в кластере-приемнике:
psql -h <IP-адрес_или_FQDN_хоста-мастера_кластера-приемника> \ -U <имя_пользователя> \ -p 6432 \ -d <имя_БД> \ < /tmp/seq-data.sql
Удалите подписку и перенесите нагрузку
-
Удалите подписку в кластере-приемнике:
DROP SUBSCRIPTION s_data_migration;
-
Перенесите нагрузку на кластер-приемник.
Удалите созданные ресурсы
Удалите ресурсы, которые вы больше не будете использовать, чтобы за них не списывалась плата:
-
В терминале перейдите в директорию с планом инфраструктуры.
-
Удалите конфигурационный файл
data-migration-pgsql-mpg.tf
. -
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
Все ресурсы, которые были описаны в конфигурационном файле
data-migration-pgsql-mpg.tf
, будут удалены. -
Перенос данных через создание и восстановление логического дампа
Создайте дамп нужной базы в кластере-источнике с помощью утилиты pg_dump
. Для восстановления дампа в кластере-приемнике используйте утилиту pg_restore
.
Примечание
Для использования утилиты pg_restore
может понадобиться расширение базы данных pg_repack
.
Этапы миграции:
- Создайте дамп переносимой базы.
- (Опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп БД на нее.
- Восстановите данные из дампа в кластер-приемник.
Если созданные ресурсы вам больше не нужны, удалите их.
Перед началом работы
Создайте необходимые ресурсы:
-
Создайте кластер-приемник Managed Service for PostgreSQL любой подходящей конфигурации. При этом следующие параметры должны быть такими же, как и в кластере-источнике:
-
Версия PostgreSQL.
-
Имя пользователя.
Примечание
Вы можете использовать различные имена пользователей для источника и приемника, но это может привести к ошибке при восстановлении дампа. Подробнее см. в разделе Перемещение и восстановление кластера PostgreSQL
-
-
(Опционально) Создайте виртуальную машину на базе Ubuntu 20.04 LTS со следующими параметрами:
-
Диски и файловые хранилища → Размер — достаточный для хранения распакованного и нераспакованного дампов.
Рекомендуется использовать объем в два или более раз превышающий суммарный объем дампа и архива с ним.
-
Сетевые настройки:
- Подсеть — выберите подсеть в той же облачной сети, в которой размещен кластер-приемник.
- Публичный адрес — выберите
Автоматически
или один адрес из списка зарезервированных IP-адресов.
-
-
Если вы используете группы безопасности для промежуточной виртуальной машины и кластера Managed Service for PostgreSQL, настройте их.
-
Если у вас еще нет Terraform, установите его.
-
Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.
-
Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.
-
Скачайте в ту же рабочую директорию файл конфигурации data-restore-pgsql-mpg.tf
.В этом файле описаны:
- сеть;
- подсеть;
- группа безопасности и правило, необходимое для подключения к кластеру;
- кластер Managed Service for PostgreSQL с публичным доступом из интернета;
- (опционально) виртуальная машина с публичным доступом из интернета.
-
Укажите в файле
data-restore-pgsql-mpg.tf
:-
pg-extensions
– список расширений PostgreSQL в кластере-источнике; -
параметры кластера-приемника:
-
target_pgsql_version
— версия PostgreSQL, она должна быть не ниже чем в кластере-источнике; -
target_db_name
— имя базы данных; -
target_user
— имя пользователя-владельца базы данных. Должно совпадать с именем пользователя в кластере-источнике;Примечание
Вы можете использовать различные имена пользователей для источника и приемника, но это может привести к ошибке при восстановлении дампа. Подробнее см. в разделе Перемещение и восстановление кластера PostgreSQL
-
target_password
— пароль пользователя-владельца базы данных;
-
-
(опционально) параметры виртуальной машины:
vm_image_id
— идентификатор публичного образа с Ubuntu без GPU. Например, для Ubuntu 20.04 LTS;vm_username
иvm_public_key
— логин и абсолютный путь к публичному ключу, которые будут использоваться для доступа к виртуальной машине. По умолчанию в образе Ubuntu 20.04 LTS указанный логин игнорируется, вместо него создается пользователь с логиномubuntu
. Используйте его для подключения к виртуальной машине.
-
-
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Создайте необходимую инфраструктуру:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления
. -
Создайте дамп базы данных
-
Переключите базу в режим
только чтение
. -
Создайте дамп с помощью утилиты pg_dump
. Для ускорения процесса запустите ее в многопоточном режиме, передав в аргументе--jobs
количество доступных ядер процессора:pg_dump --host=<IP-адрес_или_FQDN_хоста-мастера_кластера-источника> \ --port=<порт> \ --username=<имя_пользователя> \ --jobs=<количество_ядер_процессора> \ --format=d \ --dbname=<имя_БД> \ --file=db_dump
(Опционально) Загрузите дамп на виртуальную машину в Yandex Cloud
Переносить данные на промежуточную виртуальную машину в Compute Cloud нужно, если:
- К вашему кластеру Managed Service for PostgreSQL нет доступа из интернета.
- Ваше оборудование или соединение с кластером в Yandex Cloud недостаточно надежны.
Нужное количество оперативной памяти и ядер процессора зависит от объема переносимых данных и требуемой скорости переноса.
Чтобы подготовить виртуальную машину для восстановления дампа:
-
В консоли управления создайте новую виртуальную машину из образа Ubuntu 20.04 на Marketplace. Параметры виртуальной машины должны зависеть от размера базы, которую вы хотите перенести. Минимальной конфигурации (1 ядро, 2 ГБ RAM, 10 ГБ дискового пространства) должно хватить для переноса базы до 1 ГБ. Чем больше переносимая база, тем больше должно быть оперативной памяти, и тем больше должно быть дискового пространства (как минимум в два раза больше, чем размер базы).
Виртуальная машина должна находиться в той же сети и зоне доступности, что и кластер PostgreSQL. Кроме того, виртуальной машине должен быть присвоен публичный IP-адрес, чтобы вы могли загрузить дамп извне Yandex Cloud.
-
Настройте apt-репозиторий PostgreSQL
. -
Установите клиент PostgreSQL и дополнительные утилиты для работы с СУБД:
sudo apt install postgresql-client-common # Для PostgreSQL 10 sudo apt install postgresql-client-10 # Для PostgreSQL 11 sudo apt install postgresql-client-11 # Для PostgreSQL 12 sudo apt install postgresql-client-12 # Для PostgreSQL 13 sudo apt install postgresql-client-13 # Для PostgreSQL 14 sudo apt install postgresql-client-14
-
Упакуйте дамп в архив:
tar -cvzf db_dump.tar.gz db_dump
-
Перенесите архив с дампом на виртуальную машину, например, используя утилиту
scp
:scp db_dump.tar.gz <имя_пользователя_ВМ>@<публичный_адрес_ВМ>:/db_dump.tar.gz
-
Распакуйте архив с дампом:
tar -xzf db_dump.tar.gz
Восстановите данные из дампа в кластер-приемник
Восстановите дамп базы данных с помощью утилиты pg_restore
Версия pg_restore
должна совпадать с версией pg_dump
, а мажорная версия должна быть не меньше, чем у базы на которую дамп разворачивается.
Таким образом, для восстановления дампа PostgreSQL 10, PostgreSQL 11, PostgreSQL 12, PostgreSQL 13 и PostgreSQL 14 используйте pg_restore 10
, pg_restore 11
, pg_restore 12
, pg_restore 13
, pg_restore 14
соответственно.
pg_restore --host=<IP-адрес_или_FQDN_хоста-мастера_кластера-приемника> \
--username=<имя_пользователя> \
--dbname=<имя_БД> \
--port=6432 \
--format=d \
--verbose \
db_dump \
--single-transaction \
--no-privileges
Если нужно восстановить только одну схему, добавьте параметр --schema=<имя_схемы>
. Без него команда сработает только от лица владельца базы данных.
Если восстановление прерывается из-за ошибок отсутствия необходимых прав для создания и изменения расширений, уберите из команды параметр --single-transaction
. В этом случае ошибки будут проигнорированы:
pg_restore: warning: errors ignored on restore: 3
Убедитесь, что ошибки относятся только к расширениям, и проверьте целостность восстановленных данных.
Удалите созданные ресурсы
Удалите ресурсы, которые вы больше не будете использовать, чтобы за них не списывалась плата:
- Удалите кластер Yandex Managed Service for PostgreSQL.
- Если вы создавали промежуточную виртуальную машину, удалите ее.
- Если вы зарезервировали публичные статические IP-адреса, освободите и удалите их.
-
В терминале перейдите в директорию с планом инфраструктуры.
-
Удалите конфигурационный файл
data-restore-pgsql-mpg.tf
. -
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
Все ресурсы, которые были описаны в конфигурационном файле
data-restore-pgsql-mpg.tf
, будут удалены. -