Передача данных в эндпоинт-приемник PostgreSQL
- Сценарии передачи данных в PostgreSQL
- Настройка источника данных
- Подготовка базы данных приемника
- Настройка эндпоинта-приемника PostgreSQL
- Действия с базой данных во время трансфера
- Решение проблем, возникающих при переносе данных
- Остановка сессии мастер-транзакции трансфера
- Превышение квоты на длительность соединения
- Ошибка трансфера при переносе представлений (VIEW)
- Ошибка добавления записи в таблицу по constraint
- Ошибка при переносе всех таблиц схемы
- Невозможно создать объекты с участием функций расширения
- Низкая скорость трансфера
- Не переносятся таблицы-наследники
- Не хватает слотов репликации в базе данных источника
- Перестали переноситься данные после изменения эндпоинта-источника
- Ошибка трансфера при смене хоста-мастера
- Ошибка при трансфере вложенных транзакций
- Ошибка трансфера таблиц с отложенными ограничениями
- Не удается создать слот репликации на стадии активации
- Чрезмерное увеличение журнала WAL
- Ошибка при репликации из внешнего источника
- Ошибка трансфера при переносе таблиц без первичных ключей
- Ошибка удаления таблицы при политике очистки Drop
С помощью сервиса Yandex Data Transfer вы можете переносить данные в базу PostgreSQL и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:
- Ознакомьтесь с возможными сценариями передачи данных.
- Настройте один из поддерживаемых источников данных.
- Подготовьте базу данных PostgreSQL к трансферу.
- Настройте эндпоинт-приемник в Yandex Data Transfer.
- Создайте и запустите трансфер.
- Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
- При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.
Сценарии передачи данных в PostgreSQL
-
Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.
-
Поставка данных — процесс доставки произвольных данных в целевые хранилища. Процесс поставки включает извлечение данных из очереди и их десериализацию с последующей трансформацией данных в формат целевого хранилища.
-
Загрузка данных в витрины — процесс трансфера подготовленных данных в хранилища с целью последующей визуализации.
Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.
Настройка источника данных
Настройте один из поддерживаемых источников данных:
- PostgreSQL;
- MySQL®;
- Greenplum®;
- Apache Kafka®;
- Airbyte®;
- YDS;
- Yandex Object Storage;
- Managed Service for YDB;
- Oracle.
Полный список поддерживаемых источников и приемников в Yandex Data Transfer см. в разделе Доступные трансферы.
Подготовка базы данных приемника
-
Убедитесь, что мажорная версия PostgreSQL на приемнике не ниже версии на источнике.
-
При трансфере из PostgreSQL включите те же расширения в базе приемника, что и в базе источника.
Если в базе источника расширения установлены в пользовательскую схему, и эти расширения используются в DDL переносимых объектов, то вручную создайте в приемнике DDL. В этих DDL обращение к функции должно быть без указания схемы. В политике очистки эндпоинта-приемника установите значение
Truncate
, чтобы трансфер не удалил эти объекты. -
Выберите политику очистки таблиц трансфера
Drop
.Если вы вручную создали в приемнике DDL, используйте политику
Truncate
. При политикеTruncate
эти DDL не будут удалены. -
Создайте пользователя с доступом к базе приемника.
-
Выдайте созданному пользователю все привилегии на базу данных, схемы и переносимые таблицы:
GRANT ALL PRIVILEGES ON DATABASE <имя_базы> TO <имя_пользователя>;
Если база не пустая, то пользователь должен быть ее владельцем (owner):
ALTER DATABASE <имя_базы> OWNER TO <имя_пользователя>;
После старта трансфер подключится к приемнику от имени этого пользователя.
-
Если в приемнике включена опция сохранение границ транзакций, выдайте созданному пользователю все привилегии на создание служебной таблицы
__data_transfer_lsn
в текущей схеме (обычноpublic
) на приемнике:GRANT ALL PRIVILEGES ON SCHEMA <имя_схемы> TO <имя_пользователя>;
-
Настройте количество подключений пользователя к базе данных.
-
Убедитесь, что настройки сети, в которой размещен кластер, разрешают подключение к нему из интернета с IP-адресов, используемых сервисом Data Transfer
. -
Убедитесь, что мажорная версия PostgreSQL на приемнике не ниже версии на источнике.
-
Включите те же расширения в базе приемника, что и в базе источника.
-
Убедитесь, что на приемнике выбрана политика очистки
DROP таблиц трансфера
. -
Создайте пользователя:
CREATE ROLE <имя_пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';
-
Выдайте созданному пользователю все привилегии на базу данных, схемы и переносимые таблицы:
GRANT ALL PRIVILEGES ON DATABASE <имя_базы> TO <имя_пользователя>;
Если база не пустая, то пользователь должен быть ее владельцем (owner):
ALTER DATABASE <имя_базы> OWNER TO <имя_пользователя>;
После старта трансфер подключится к приемнику от имени этого пользователя.
-
Если в приемнике включена опция сохранение границ транзакций, выдайте созданному пользователю все привилегии на создание служебной таблицы
__data_transfer_lsn
в текущей схеме (обычноpublic
) на приемнике:GRANT ALL PRIVILEGES ON SCHEMA <имя_схемы> TO <имя_пользователя>;
-
Настройте количество подключений пользователя к базе данных.
Данные, хранящиеся в MATERIALIZED VIEW
, не переносятся. Для переноса данных из MATERIALIZED VIEW
создайте обыкновенный VIEW
, ссылающийся на переносимый MATERIALIZED VIEW
.
Если определение переносимого VIEW
содержит вызов VOLATILE
функцииVIEW
с уровнем изоляции READ UNCOMMITTED
. Консистентность между данными в этом VIEW
и данными других переносимых объектов не гарантируется. Чтение из MATERIALIZED VIEW
в определении VIEW
равносильно вызову VOLATILE
функции.
Настройка эндпоинта-приемника PostgreSQL
При создании или изменении эндпоинта вы можете задать:
- Настройки подключения к кластеру Yandex Managed Service for PostgreSQL или пользовательской инсталляции, в т. ч. на базе виртуальных машин Yandex Compute Cloud. Эти параметры обязательные.
- Дополнительные параметры.
Кластер Managed Service for PostgreSQL
Важно
Для создания или редактирования эндпоинта управляемой базы данных вам потребуется роль managed-postgresql.viewer
или примитивная роль viewer
, выданная на каталог кластера этой управляемой базы данных.
Подключение к БД с указанием идентификатора кластера в Yandex Cloud.
-
Кластер Managed Service for PostgreSQL — укажите идентификатор кластера, к которому необходимо подключиться.
-
Тип подключения — выберите вариант подключения к базе данных:
-
Ручная настройка — позволяет задать настройки подключения вручную:
-
База данных — укажите имя базы данных в выбранном кластере.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
-
Connection Manager — позволяет использовать подключение к базе данных через Yandex Connection Manager:
-
Подключение — укажите идентификатор подключения из Connection Manager.
-
База данных — укажите имя базы данных в выбранном кластере.
Важно
Чтобы использовать подключение из Connection Manager, у пользователя должны быть права доступа не ниже
connection-manager.user
к этому подключению. -
-
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.
- Тип эндпоинта —
postgres-target
.
-
--cluster-id
— идентификатор кластера, к которому необходимо подключиться. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
postgres_target
.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к кластеру. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности должны принадлежать той же сети, в которой размещен кластер.
Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
connection.mdb_cluster_id
— идентификатор кластера, к которому необходимо подключиться. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
postgres_target {
security_groups = ["<список_идентификаторов_групп_безопасности>"]
connection {
mdb_cluster_id = "<идентификатор_кластера>"
}
database = "<имя_переносимой_базы_данных>"
user = "<имя_пользователя_для_подключения>"
password {
raw = "<пароль_пользователя>"
}
}
}
}
Подробнее см. в документации провайдера Terraform
-
securityGroups
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
mdbClusterId
— идентификатор кластера, к которому необходимо подключиться. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль пользователя для доступа к базе данных (в текстовом виде).
Пользовательская инсталляция
Для случая OnPremise все поля заполняются вручную.
-
Тип подключения — выберите вариант подключения к базе данных:
-
Ручная настройка — позволяет задать настройки подключения вручную:
-
Хост — укажите IP-адрес или FQDN хоста-мастера. Если на хостах открыты разные порты для подключения, то вы можете задать несколько значений хостов в формате
хост:порт
. Если вы выбираете такой формат, то значение поля Порт не будет учитываться. -
Порт — укажите номер порта, который сервис Data Transfer будет использовать для подключения.
-
База данных — укажите имя базы данных в выбранном кластере.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
Сертификат CA — загрузите файл сертификата или добавьте его содержимое в текстовом виде, если требуется шифрование передаваемых данных, например, для соответствия требованиям PCI DSS
.
-
-
Connection Manager — позволяет использовать подключение к базе данных через Yandex Connection Manager:
-
Подключение — укажите идентификатор подключения из Connection Manager.
-
База данных — укажите имя базы данных в выбранном кластере.
Важно
Чтобы использовать подключение из Connection Manager, у пользователя должны быть права доступа не ниже
connection-manager.user
к этому подключению. -
-
-
Идентификатор подсети — выберите или создайте подсеть в нужной зоне доступности.
Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.
- Тип эндпоинта —
postgres-target
.
-
--host
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
--port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
--ca-certificate
— сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS . -
--subnet-id
— идентификатор подсети, в которой находится хост. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
postgres_target
.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к ВМ c базой данных. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности должны принадлежать той же сети, что и подсеть
subnet_id
, если она указана.Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
on_premise.hosts
— список IP-адресов или FQDN хостов, к которым необходимо подключиться. Так как поддерживается только список из одного элемента, укажите адрес хоста-мастера. -
on_premise.port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
on_premise.tls_mode.enabled.ca_certificate
— сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS . -
on_premise.subnet_id
— идентификатор подсети, в которой находится хост. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
postgres_target {
security_groups = ["<список_идентификаторов_групп_безопасности>"]
connection {
on_premise {
hosts = ["<список_хостов>"]
port = <порт_для_подключения>
}
}
database = "<имя_переносимой_базы_данных>"
user = "<имя_пользователя_для_подключения>"
password {
raw = "<пароль_пользователя>"
}
}
}
}
Подробнее см. в документации провайдера Terraform
onPremise
— параметры подключения к базе данных:-
hosts
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
tlsMode
— параметры шифрования передаваемых данных, если оно требуется, например для соответствия требованиям PCI DSS . -
subnetId
— идентификатор подсети, в которой находится хост.
-
-
securityGroups
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль пользователя для доступа к базе данных (в текстовом виде).
Дополнительные настройки
-
Политика очистки — выберите способ очистки данных в базе-приемнике перед переносом:
-
Не очищать
— выберите эту опцию, если будет производиться только репликация без копирования данных. -
Drop
— полное удаление таблиц, участвующих в трансфере (вариант по умолчанию).Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия схемы таблиц из источника.
-
Truncate
— удалить только данные из таблиц, участвующих в трансфере, но оставить схему.Используйте эту опцию, если схема в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
-
-
Сохранение границ транзакций — включите, чтобы сервис записывал данные в базу-приемник только после полного чтения данных транзакции из базы-источника.
Важно
Эта функциональность находится на стадии Preview.
cleanup_policy
— способ очистки данных в базе-приемнике перед переносом:
-
DISABLED
— не очищать (вариант по умолчанию).Выберите эту опцию, если будет производиться только репликация без копирования данных.
-
DROP
— полное удаление таблиц, участвующих в трансфере.Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия схемы таблиц из источника.
-
TRUNCATE
— удалить только данные из таблиц, участвующих в трансфере, но оставить схему.Используйте эту опцию, если схема в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
cleanupPolicy
— способ очистки данных в базе-приемнике перед переносом:
-
DISABLED
— не очищать (вариант по умолчанию).Выберите эту опцию, если будет производиться только репликация без копирования данных.
-
DROP
— полное удаление таблиц, участвующих в трансфере.Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия схемы таблиц из источника.
-
TRUNCATE
— удалить только данные из таблиц, участвующих в трансфере, но оставить схему.Используйте эту опцию, если схема в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
После настройки источника и приемника данных создайте и запустите трансфер.
Действия с базой данных во время трансфера
Совет
Протокол репликации PostgreSQL не поддерживает передачу изменения схемы данных. Избегайте изменения схемы данных в базах источника и приемника во время трансфера. Если избежать этого невозможно, проведите явные проверки на приемнике.
Для трансферов типа Копирование и Копирование и репликация:
-
в статусе Копируется запрещено изменять схему данных на источнике и приемнике;
-
в статусе Реплицируется любые изменения схемы данных на источнике вручную примените на приемнике, иначе трансфер не сможет продолжить работу.
Например, пусть в таблицу
test_table
источника добавили новый столбец:ALTER TABLE test_table ADD COLUMN val2 TEXT;
Если запись в эту таблицу продолжается, трансфер не сможет выполнить вставку данных на приемнике. Чтобы репликация продолжилась, выполните аналогичный запрос на изменение схемы данных на приемнике:
ALTER TABLE test_table ADD COLUMN val2 TEXT;
После этого трансфер сможет продолжить работу.
Решение проблем, возникающих при переносе данных
Известные проблемы, связанные с использованием эндпоинта PostgreSQL:
- Остановка сессии мастер-транзакции трансфера
- Превышение квоты на длительность соединения
- Ошибка трансфера при переносе представлений (VIEW)
- Ошибка добавления записи в таблицу по constraint
- Ошибка при переносе всех таблиц схемы
- Невозможно создать объекты с участием функций расширения
- Низкая скорость трансфера
- Не переносятся таблицы-наследники
- Не хватает слотов репликации в базе данных источника
- Перестали переноситься данные после изменения эндпоинта-источника
- Ошибка трансфера при смене хоста-мастера
- Ошибка при трансфере вложенных транзакций
- Ошибка трансфера таблиц с отложенными ограничениями
- Не удается создать слот репликации на стадии активации
- Чрезмерное увеличение журнала WAL
- Ошибка при репликации из внешнего источника
- Ошибка трансфера при переносе таблиц без первичных ключей
- Ошибка удаления таблицы при политике очистки Drop
См. полный список рекомендаций в разделе Решение проблем.
Остановка сессии мастер-транзакции трансфера
Текст ошибки:
Cannot set transaction snapshot:
ERROR: invalid snapshot identifier: "<идентификатор_снапшота>" (SQLSTATE 22023).
Возможные причины:
- На источнике работает cron-задание или другое приложение, которое периодически завершает слишком длительные сессии.
- Кто-то вручную завершил мастер-транзакцию.
- Ресурсов CPU на источнике не хватает для выполнения запроса.
Решение: отключите такое cron-задание, а также добавьте дополнительные ресурсы для CPU на источник. После внесения изменений активируйте трансфер повторно.
Превышение квоты на длительность соединения
В Yandex Managed Service for PostgreSQL существует квота на длительность соединения — 12 часов.
Решение: если перенос базы данных требует больше времени, измените настройку кластера Yandex Managed Service for PostgreSQL Session duration timeout.
Ошибка трансфера при переносе представлений (VIEW)
Текст ошибки:
[ERROR] "... _view": no key columns found
Репликация новых данных из представлений невозможна. При трансфере PostgreSQL — PostgreSQL переносятся только те представления, которые указаны в параметре эндпоинта-источника Фильтр таблиц → Список включенных таблиц.
Решение: вручную исключите из трансфера все представления, записав их в параметре эндпоинта-источника Фильтр таблиц → Список исключённых таблиц, после чего активируйте трансфер повторно.
Ошибка добавления записи в таблицу по constraint
Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.
Ошибка при переносе всех таблиц схемы
Текст ошибки:
Unable to apply DDL of type 'TABLE', name '<схема>'.'<таблица>', error:
ERROR: schema "<схема>" does not exist (SQLSTATE 3F000)
Трансфер прерывается при указании списка таблиц определенной схемы в виде <схема>.*
. Это происходит из-за особенностей работы утилиты pg_dump
, которая используется для переноса схемы. При указании таблиц всей схемы <схема>.*
в параметре эндпоинта-источника Фильтр таблиц → Список включенных таблиц типы PostgreSQL из этой схемы не извлекаются, даже если в схеме есть таблицы, зависящие от этих типов.
Решение: создайте типы PostgreSQL в базе-приемнике вручную.
Невозможно создать объекты с участием функций расширения
Текст ошибки:
Unable to apply DDL of type 'TABLE', <имя_объекта>, error:
failed to push non-row item 0 of kind "pg:DDL" in batch:
Push failed: ERROR: function <имя_схемы>.<имя_функции>() does not exist
(SQLSTATE 42883)
В Managed Service for PostgreSQL в базе-приемнике невозможно установить расширение в пользовательскую схему. Поэтому трансфер прерывается, если в пользовательской инсталляции Managed Service for PostgreSQL есть расширения, установленные в пользовательскую схему, и эти расширения используются в DDL переносимых объектов.
Решение: проверьте DDL объектов, имена которых указаны в ошибке. Если в этих объектах есть вызов функций из пользовательской схемы, вручную создайте в приемнике DDL, которые вызывают функции без указания схемы. В политике очистки эндпоинта-приемника установите значение Truncate
, чтобы трансфер не удалил эти объекты.
Низкая скорость трансфера
Может возникать у трансферов типа Копирование или Копирование и репликация из PostgreSQL в PostgreSQL.
Возможные причины:
-
Протокол записи.
В нормальном режиме трансфер работает через быстрый протокол
copy
, но при конфликтах записи батча переходит на медленную построчную запись. Чем больше конфликтов записи, тем ниже скорость трансфера.Решение: установите в эндпоинте-приемнике тип политики очистки
Drop
и исключите другие пишущие процессы. -
Параллельность чтения таблиц.
Параллельность доступна только для таблиц, которые содержат первичный ключ в режиме serial
.Решение: настройте параллельное копирование и активируйте трансфер повторно.
Не переносятся таблицы-наследники
Во время трансфера не переносятся таблицы-наследники, либо переносятся без данных, если таблица партицированная.
Решение: установите следующие параметры эндпоинта-источника:
- Включите опцию Объединить наследуемые таблицы в расширенных настройках.
- Укажите в поле Список включенных таблиц все таблицы-наследники, данные которых нужно перенести.
- Убедитесь, что у пользователя есть доступ к таблицам-наследникам.
Для увеличения скорости трансфера при переносе таблиц-наследников настройте параллельное копирование.
Не хватает слотов репликации в базе данных источника
Текст ошибки:
Warn(Activate): failed to create a replication slot "<идентификатор_трансфера>" at source:
failed to create a replication slot:
failed to create a replication slot:
ERROR: all replication slots are in use
(SQLSTATE 53400)
Решение: увеличьте количество слотов репликации10
).
Перестали переноситься данные после изменения эндпоинта-источника
После добавления таблиц в Список включенных таблиц в параметрах эндпоинта-источника трансфер перезапустился и перестал переносить данные.
Решение:
-
Создайте таблицы в базе-приемнике вручную.
1. Создайте в базе-приемнике новые таблицы с
Primary Key
и безForeign key
.
2. Добавьте новые таблицы в Список включенных таблиц в параметрах эндпоинта-источника.
3. Перенесите дамп с историческими данными в базу-приемник.
4. При появлении в логах ошибок решите их согласно конкретной ошибке.
5. Если ошибок нет, но логи пусты, обратитесь в техническую поддержку или к вашему аккаунт-менеджеру для снятия дампа горутин. Это может помочь восстановить репликацию без повторного запуска трансфера. -
Деактивируйте и активируйте трансфер повторно.
-
Создайте отдельный трансфер типа Копирование для новых таблиц. При этом исходный трансфер можно не деактивировать.
Ошибка трансфера при смене хоста-мастера
Ошибка возникает в трансферах типа Репликация или Копирование и репликация из-за отсутствия нужных частей Write-Ahead Log (WAL). Это происходит, когда отставание логической репликации WAL с текущего мастера на реплику превышает доступный объем WAL на других хостах. Поэтому при переключении мастера на эту реплику слот репликации не может синхронизироваться с WAL на новом мастере.
Решение: увеличьте лимит в дополнительном параметре эндпоинта-источника Максимальный размер WAL для слота репликации и активируйте трансфер повторно.
Ошибка при трансфере вложенных транзакций
Трансфер PostgreSQL версий ниже 14 не поддерживает перенос таблиц с примененными транзакциями, которые вложены более 1024 раз и на каждом уровне вложенности есть изменения для репликации. Количество вложенностей определяется по числу вложенных конструкций begin; .. commit;
.
Решение:
- Используйте PostgreSQL версии 14 или выше.
- Исключите из трансфера транзакции с таким уровнем вложенности.
Ошибка трансфера таблиц с отложенными ограничениями
Ошибка возникает в трансферах типа Репликация или Копирование и репликация, так как обновление таблиц и транзакций с отложенными (DEFERRABLE
) ограничениями не поддерживается Data Transfer. Подробнее об отложенных ограничениях см. в документации PostgreSQL
Решение: замените тип ограничений в таких таблицах на IMMEDIATE
и активируйте трансфер повторно.
Не удается создать слот репликации на стадии активации
В начале работы трансфера создается один или несколько слотов репликации
Решение:
-
Найдите
PID
процесса, конкурирующего за блокировки с трансфером:/* поиск PID трансфера */ SELECT active_pid FROM pg_replication_slots WHERE slot_name = '<ID_трансфера>'; /* поиск PID блокирующего процесса */ SELECT pid, pg_blocking_pids(pid) as blocked_by FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid)) > 0;
pid | blocked_by -----------------+------------------- <PID_трансфера> | {<PID_блокирующей_транзакции>} (1 row)
-
Посмотрите блокирующий запрос:
SELECT query, usename FROM pg_stat_activity WHERE pid = <PID_блокирующей_транзакции>;
-
(Опционально) Остановите транзакцию командой:
SELECT pg_terminate_backend(<PID_блокирующей_транзакции>);
-
Активируйте трансфер повторно.
Чрезмерное увеличение журнала WAL
В базе данных источника PostgreSQL размер журнала Write-Ahead Log (WAL) достигает значения десятков гигабайт из-за долгих запросов (выполняющихся более 5 минут). Такие запросы блокируют журнал WAL и не дают ему продвинуться вперед и очиститься.
Увеличение размера журнала WAL можно заметить по:
- увеличению места, занимаемого базой данных источника;
- возрастанию графика Read buffer size в мониторинге Data Transfer.
Решение:
-
Найдите сессии запросов, выполняющиеся дольше 5 минут:
SELECT now()-xact_start, query, pid FROM pg_stat_activity WHERE (now()-xact_start)>'5minute'::interval AND STATE != 'idle' ORDER BY 1 DESC;
-
Завершите найденные сессии. Старайтесь не допускать появления таких запросов.
Ошибка при репликации из внешнего источника
Текст ошибки:
[XX000] ERROR: could not connect to the publisher:
SSL error: certificate verify failed FATAL:
no pg_hba.conf entry for replication connection
from host "<IP-адрес_хоста_PostgreSQL>", user "postgres", SSL off
Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.
Ошибка трансфера при переносе таблиц без первичных ключей
Текст ошибки:
Primary key check failed: 14 Tables errors: Table no key columns found
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся.
Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.
Ошибка удаления таблицы при политике очистки Drop
Текст ошибки:
ERROR: cannot drop table <имя_таблицы> because other objects depend on it (SQLSTATE 2BP01)
При политике очистки Drop
трансфер удаляет таблицы в несколько итераций:
-
Трансфер последовательно пытается удалить все таблицы. Каскадное удаление не используется, так как может привести к удалению таблиц, не участвующих в трансфере. Если таблицу невозможно удалить, например, из-за связанности внешними ключами, возникает ошибка, но трансфер продолжит удаление таблиц.
-
Во время следующей итерации трансфер пытается удалить оставшиеся таблицы. Если блокирующие дочерние таблицы были удалены в предыдущей итерации, таблица со связанностью внешними ключами удаляется. В этом случае ошибка устраняется в процессе работы Data Transfer, дополнительных действий не требуется.
-
Если во время очередной итерации трансфер не удалил ни одной таблицы, процесс удаления таблиц завершается. При этом:
- Трансфер продолжит работу, если все таблицы были удалены.
- Трансфер прервется с ошибкой, если остались неудаленные таблицы.
Решение:
-
Если дочерние таблицы не участвуют в других трансферах и их перенос не противоречит целям трансфера, добавьте эти таблицы:
- В список включенных таблиц в параметрах эндпоинта-источника.
- В список объектов для переноса в параметрах трансфера.
-
Удалите блокирующие дочерние таблицы в базе-приемнике вручную.
-
Используйте политику очистки
Truncate
. -
Пересоздайте базу в приемнике.
Важно
Это приведет к потере всех данных в базе.