Передача данных из эндпоинта-источника PostgreSQL
- Сценарии передачи данных из PostgreSQL
- Подготовка базы данных источника
- Настройка эндпоинта-источника PostgreSQL
- Настройка приемника данных
- Действия с базой данных во время трансфера
- Решение проблем, возникающих при переносе данных
- Остановка сессии мастер-транзакции трансфера
- Превышение квоты на длительность соединения
- Ошибка трансфера при переносе представлений (VIEW)
- Ошибка добавления записи в таблицу по constraint
- Ошибка при переносе всех таблиц схемы
- Невозможно создать объекты с участием функций расширения
- Низкая скорость трансфера
- Не переносятся таблицы-наследники
- Не хватает слотов репликации в базе данных источника
- Перестали переноситься данные после изменения эндпоинта-источника
- Ошибка трансфера при смене хоста-мастера
- Ошибка при трансфере вложенных транзакций
- Ошибка трансфера таблиц с отложенными ограничениями
- Не удается создать слот репликации на стадии активации
- Чрезмерное увеличение журнала WAL
- Ошибка при репликации из внешнего источника
- Ошибка трансфера при переносе таблиц без первичных ключей
- Ошибка удаления таблицы при политике очистки Drop
С помощью сервиса Yandex Data Transfer вы можете переносить данные из базы PostgreSQL и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:
- Ознакомьтесь с возможными сценариями передачи данных.
- Подготовьте базу данных PostgreSQL к трансферу.
- Настройте эндпоинт-источник в Yandex Data Transfer.
- Настройте один из поддерживаемых приемников данных.
- Создайте и запустите трансфер.
- Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
- При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.
Сценарии передачи данных из PostgreSQL
-
Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.
-
Захват изменений данных — это процесс отслеживания изменений в базе данных и поставка этих изменений потребителям. Применяется для приложений, которые чувствительны к изменению данных в реальном времени.
-
Загрузка данных в витрины — процесс трансфера подготовленных данных в хранилища с целью последующей визуализации.
-
Загрузка данных в масштабируемое хранилище Object Storage позволяет удешевить хранение и облегчает обмен данных с контрагентами.
Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.
Подготовка базы данных источника
Примечание
При трансфере из PostgreSQL в любой тип приемника объекты типа large objects
При переносе данных с типом TIMESTAMP WITHOUT TIME ZONE
применяется часовой пояс, указанный в параметре timezone
базы данных источника PostgreSQL.
Пример
В колонке с типом данных TIMESTAMP WITHOUT TIME ZONE
записано значение 1970-01-01 00:00:00
. То, как при трансфере будет перенесено значение, зависит от параметра timezone
в БД:
- Если значение параметра равно
Etc/UTC
, то время переносится как1970-01-01 00:00:00+00
. - Если значение параметра равно
Europe/Moscow
, то время переносится как1970-01-01 00:00:00+03
.
Данные, хранящиеся в MATERIALIZED VIEW
, не переносятся. Для переноса данных из MATERIALIZED VIEW
создайте обыкновенный VIEW
, ссылающийся на переносимый MATERIALIZED VIEW
.
Если определение переносимого VIEW
содержит вызов VOLATILE
функцииVIEW
с уровнем изоляции READ UNCOMMITTED
. Консистентность между данными в этом VIEW
и данными других переносимых объектов не гарантируется. Чтение из MATERIALIZED VIEW
в определении VIEW
равносильно вызову VOLATILE
функции.
Большие объекты в системе хранения TOAST
-
Настройте пользователя, от имени которого трансфер подключится к источнику:
-
Для типов трансфера Репликация и Копирование и репликация назначьте роль
mdb_replication
этому пользователю. -
Подключитесь к базе данных, которую нужно мигрировать, от имени владельца базы и настройте привилегии:
SELECT
над всеми таблицами базы данных, которые переносит трансфер;SELECT
над всеми последовательностями базы данных, которые переносит трансфер;USAGE
на схемы этих таблиц и последовательностей.ALL PRIVILEGES
(CREATE
иUSAGE
) на задаваемую параметром эндпоинта схему служебных таблиц__consumer_keeper
и__data_transfer_mole_finder
, если эндпоинт будет использоваться для типов трансфера Репликация или Копирование и репликация.
-
Настройте количество подключений пользователя к базе данных.
-
Если источник репликации — кластер, включите для него расширение
pg_tm_aux
. Это позволит продолжить репликацию в случае смены хоста-мастера. В некоторых случаях при смене мастера в кластере трансфер может завершиться ошибкой. Подробнее см. в разделе Решение проблем. -
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся. Чтобы сохранить работоспособность трансфера при переносе базы с такими таблицами:
- Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
- Добавьте идентификатор реплики на таблицах без
primary key
:-
Для таблиц с индексом установите
REPLICA IDENTITY
поunique key
:ALTER TABLE MY_TBL REPLICA IDENTITY USING INDEX MY_IDX;
-
Для таблиц без индекса измените
REPLICA IDENTITY
:ALTER TABLE MY_TBL REPLICA IDENTITY FULL;
В этом случае Data Transfer будет воспринимать такие таблицы как таблицы, в которых первичный ключ является составным, и в него входят все колонки таблицы.
-
Если в таблице нет первичных ключей, тогда в логической репликации не будет событий изменений строк
(UPDATE
,DELETE
).-
Во время трансфера из PostgreSQL в PostgreSQL, если у вас в источнике трансфера не будет исключена таблица без первичных ключей, то вы увидите ошибку:
failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed: "public"."MY_TBL": no key columns found
-
Во время трансфера из PostgreSQL в другую базу данных, если у вас будет добавлена таблица без первичных ключей, то вы увидите ошибку:
failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed: "public"."MY_TBL": no key columns found
-
Выключите перенос внешних ключей на стадии создания эндпоинта-источника. Создайте их заново после окончания трансфера.
-
Найдите и завершите слишком долгие DDL-запросы. Для этого сделайте выборку из системной таблицы PostgreSQL
pg_stat_activity
:SELECT NOW() - query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' ORDER BY 1 DESC;
Будет возвращен список запросов, выполняющихся на сервере. Обратите внимание на запросы с высоким значением
duration
. -
Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Репликация и Копирование и репликация). Подробнее см. в описании дополнительных настроек эндпоинта для источника PostgreSQL.
-
Для параллельного чтения из таблицы установите ее первичный ключ в режим serial
.После этого укажите количество воркеров и потоков в блоке Среда выполнения в параметрах трансфера.
-
Настройте мониторинг WAL-лога.
Для трансферов типа Репликация и Копирование и репликация используется логическая репликация
. Для этого сам трансфер создает слот репликации со значениемslot_name
, равным идентификатору трансфера, который можно получить, выбрав трансфер в списке ваших трансферов. WAL может расти по разным причинам: из-за долгой транзакции или из-за проблемы на трансфере. Поэтому рекомендуется настроить мониторинг WAL-лога на стороне источника.-
Для мониторинга размера использованного хранилища или диска настройте алерт средствами мониторинга (см. описание
disk.used_bytes
). -
Задайте максимальный размер WAL при репликации в настройке
Max slot wal keep size
. Редактирование данной настройки доступно начиная с 13 версии PostgreSQL. Если вы хотите экстренно запретить операции чтения трансферу, то удалите слот репликации.Важно
При значении настройки
-1
(размер не ограничен) открытые логические слоты репликации, из которых не считывается информация, будут препятствовать удалению WAL-файлов. В результате WAL-файлы займут все дисковое пространство и вы потеряете возможность подключаться к кластеру. -
Настройте алерт средствами Yandex Monitoring на метрику, которая используется для
Total size of WAL files
. Пороговые значения должны быть меньше, чем указаны для метрикиdisk.used_bytes
, так как на диске, кроме данных, хранятся временные файлы, WAL-лог и другие типы данных. Текущий размер слота можно мониторить средствами БД через запрос, указав правильныйslot_name
, равный идентификатору трансфера:SELECT slot_name, pg_size_pretty(pg_current_wal_lsn() - restart_lsn), active_pid, catalog_xmin, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots WHERE slot_name = '<идентификатор_трансфера>'
-
Настройка
-
В файле
postgresql.conf
измените значение параметраwal_level
наlogical
:wal_level = logical
-
Перезапустите PostgreSQL.
Если источник репликации — кластер, установите и включите на его хостах расширение pg_tm_aux
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся. Чтобы сохранить работоспособность трансфера при переносе базы с такими таблицами:
- Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
- Добавьте идентификатор реплики на таблицах без
primary key
:-
Для таблиц с индексом установите
REPLICA IDENTITY
поunique key
:ALTER TABLE MY_TBL REPLICA IDENTITY USING INDEX MY_IDX;
-
Для таблиц без индекса измените
REPLICA IDENTITY
:ALTER TABLE MY_TBL REPLICA IDENTITY FULL;
В этом случае Data Transfer будет воспринимать такие таблицы как таблицы, в которых первичный ключ является составным, и в него входят все колонки таблицы.
-
Если в таблице нет первичных ключей, тогда в логической репликации не будет событий изменений строкUPDATE
, DELETE
).
-
Во время трансфера из PostgreSQL в PostgreSQL, если у вас в источнике трансфера не будет исключена таблица без первичных ключей, то вы увидите ошибку:
failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed: "public"."MY_TBL": no key columns found
-
Во время трансфера из PostgreSQL в другую базу данных, если у вас будет добавлена таблица без первичных ключей, то вы увидите ошибку:
failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed: "public"."MY_TBL": no key columns found
Выключите перенос внешних ключей на стадии создания эндпоинта-источника. Создайте их заново после окончания трансфера.
Найдите и завершите слишком долгие DDL-запросы. Для этого сделайте выборку из системной таблицы PostgreSQL pg_stat_activity
:
SELECT NOW() - query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' ORDER BY 1 DESC;
Будет возвращен список запросов, выполняющихся на сервере. Обратите внимание на запросы с высоким значением duration
.
Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Репликация и Копирование и репликация). Подробнее см. в описании дополнительных настроек эндпоинта для источника PostgreSQL.
Для параллельного чтения из таблицы установите ее первичный ключ в режим serial
После этого укажите количество воркеров и потоков в блоке Среда выполнения в параметрах трансфера.
Если на источнике настроена репликация через Patroni
ignore_slots:
- database: <база_данных>
name: <слот_репликации>
plugin: wal2json
type: logical
Где:
database
— имя базы данных, для которой настроен трансфер.name
— имя слота репликации.
Имя базы данных и имя слота репликации должны совпадать со значениями, указанными в настройках эндпоинта для источника. По умолчанию имя слота репликации
совпадает с ID трансфера
.
В противном случае начало этапа репликации завершится ошибкой:
Warn(Termination): unable to create new pg source: Replication slotID <имя_слота_репликации> does not exist.
Настройте мониторинг WAL-лога. Для трансферов типа Репликация и Копирование и репликация используется логическая репликацияslot_name
, равным идентификатору трансфера, который можно получить, выбрав трансфер в списке ваших трансферов. WAL может расти по разным причинам: из-за долгой транзакции или из-за проблемы на трансфере. Поэтому рекомендуется настроить мониторинг WAL-лога на стороне источника.
-
Настройте алерты на основе рекомендаций по использованию диска
. -
Установите максимальный размер WAL
. Эта возможность доступна, начиная с версии PostgreSQL 13. -
Текущий размер слота можно отслеживать средствами БД через запрос, указав правильный
slot_name
, равный идентификатору трансфера:SELECT slot_name, pg_size_pretty(pg_current_wal_lsn() - restart_lsn), active_pid, catalog_xmin, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots WHERE slot_name = '<идентификатор_трансфера>'
Примечание
Об особенностях переноса данных из PostgreSQL в ClickHouse® трансферами типа Репликация и Копирование и репликация см. в разделе Асинхронная репликация данных из PostgreSQL в ClickHouse®.
Настройка эндпоинта-источника PostgreSQL
При создании или изменении эндпоинта вы можете задать:
- Настройки подключения к кластеру Yandex Managed Service for PostgreSQL или пользовательской инсталляции, в т. ч. на базе виртуальных машин Yandex Compute Cloud. Эти параметры обязательные.
- Дополнительные параметры.
Перед началом работы ознакомьтесь с особенностями работы сервиса с источниками и приемниками PostgreSQL.
Кластер 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-source
.
-
--cluster-id
— идентификатор кластера, к которому необходимо подключиться. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
postgres_source
.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к кластеру. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности должны принадлежать той же сети, в которой размещен кластер.
Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
connection.mdb_cluster_id
— идентификатор кластера, к которому необходимо подключиться. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
postgres_source {
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-source
.
-
--host
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
--port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
--ca-certificate
— сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS . -
--subnet-id
— идентификатор подсети, в которой находится хост. Трансфер будет использовать эту подсеть для доступа к хосту. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
postgres_source
.
-
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_source {
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
— пароль пользователя для доступа к базе данных (в текстовом виде).
Дополнительные настройки
-
Фильтр таблиц:
-
Список включённых таблиц — будут передаваться данные только из таблиц этого списка.
Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
Список исключённых таблиц — данные таблиц из этого списка передаваться не будут.
Списки включают имя схемы
(описание содержания, структуры и ограничений целостности базы данных) и имя таблицы. Для обоих списков поддерживаются выражения вида:<имя_схемы>.<имя_таблицы>
— полное имя таблицы;<имя_схемы>.*
— все таблицы в указанной схеме.
Имена таблиц должны соответствовать регулярному выражению:
^"?[-_a-zA-Z0-9.]+"?\\."?[$-_a-zA-Z0-9.*]+"?$
Двойные кавычки внутри имени таблицы не поддерживаются. Внешние кавычки используются только как разделители и будут удалены при обработке путей.
Важно
Сервис не переносит пользовательские типы данных, если в эндпоинте для источника задан список включенных таблиц. В этом случае перенесите пользовательские типы данных вручную.
-
-
Перенос схемы — при необходимости выберите элементы схемы БД, которые будут перенесены в процессе активации или деактивации трансфера.
-
Расширеннные настройки:
-
Максимальный размер WAL для слота репликации — максимальный размер Write-Ahead Log, удерживаемого слотом репликации. При превышении этого ограничения репликация останавливается и слот репликации удаляется. Значение по умолчанию — 50 ГБ. Данная настройка не обеспечивает защиту от переполнения диска на базе данных источника. Ее возможно использовать только для версии PostgreSQL ниже 13, а рекомендованный способ — это мониторинг значения слота WAL-лога на базе данных источника.
Важно
Использование настройки Максимальный размер WAL для слота репликации не гарантирует удаление слота репликации при превышении указанного в настройке значения в тех случаях, когда нарушена работа трансфера или доступность от трансфера до кластера-источника. См. рекомендации в разделе Подготовка базы данных источника.
-
Схема базы данных для служебных таблиц — укажите имя схемы для хранения служебных таблиц (
__consumer_keeper
,__data_transfer_mole_finder
).
Имя схемы должно соответствовать регулярному выражению:
^[-_a-zA-Z0-9]*$
Двойные кавычки в имени схемы не поддерживаются.
-
Объединить наследуемые таблицы — выберите для объединения содержимого таблиц. Подробнее см. в разделе Особенности работы с эндпоинтами.
-
Настройки параллельного копирования таблиц — при необходимости задайте детальные настройки параллельного копирования таблиц (если в трансфере заданы параметры параллельного копирования).
-
-
--include-table
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
--exclude-table
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут.Списки включают имя схемы (описание содержания, структуры и ограничений целостности базы данных) и имя таблицы. Для обоих списков поддерживаются выражения вида:
<имя_схемы>.<имя_таблицы>
— полное имя таблицы;<имя_схемы>.*
— все таблицы в указанной схеме.
Важно
Сервис не переносит пользовательские типы данных, если в эндпоинте для источника задан список включенных таблиц. В этом случае перенесите пользовательские типы данных вручную.
-
--slot-lag-limit
— максимальный размер Write-Ahead Log, удерживаемого слотом репликации. При превышении этого ограничения репликация останавливается и слот репликации удаляется. Значение по умолчанию – 50 ГБ. -
--service-schema
— имя схемы БД для служебных таблиц. -
Настройки переноса схемы:
--transfer-before-data
— на первичной стадии трансфера.--transfer-after-data
— на финальной стадии трансфера.
-
include_tables
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
exclude_tables
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут.Списки включают имя схемы (описание содержания, структуры и ограничений целостности базы данных) и имя таблицы. Для обоих списков поддерживаются выражения вида:
<имя_схемы>.<имя_таблицы>
— полное имя таблицы;<имя_схемы>.*
— все таблицы в указанной схеме.
Важно
Сервис не переносит пользовательские типы данных, если в эндпоинте для источника задан список включенных таблиц. В этом случае перенесите пользовательские типы данных вручную.
-
slot_gigabyte_lag_limit
— максимальный размер Write-Ahead Log, удерживаемого слотом репликации. При превышении этого ограничения репликация останавливается и слот репликации удаляется. Значение по умолчанию – 50 ГБ. -
service_schema
— имя схемы БД для служебных таблиц. -
object_transfer_settings
— настройки переноса схемы:sequence
— последовательности;sequence_owned_by
— пользовательские последовательности;table
— таблицы;primary_key
— первичные ключи;fk_constraint
— внешние ключи;default_values
— значения по умолчанию;constraint
— ограничения;index
— индексы;view
— представления;function
— функции;trigger
— триггеры;type
— типы;rule
— правила;collation
— правила сортировки;policy
— политики;cast
— приведения типов.
Для каждой сущности может быть задано одно из значений:
BEFORE_DATA
— перенос на этапе активации трансфера;AFTER_DATA
— перенос на этапе деактивации трансфера;NEVER
— не переносить.
Подробнее см. в документации провайдера Terraform
-
includeTables
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
excludeTables
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут.Списки включают имя схемы (описание содержания, структуры и ограничений целостности базы данных) и имя таблицы. Для обоих списков поддерживаются выражения вида:
<имя_схемы>.<имя_таблицы>
— полное имя таблицы;<имя_схемы>.*
— все таблицы в указанной схеме.
Важно
Сервис не переносит пользовательские типы данных, если в эндпоинте для источника задан список включенных таблиц. В этом случае перенесите пользовательские типы данных вручную.
-
slotByteLagLimit
— максимальный размер Write-Ahead Log, удерживаемого слотом репликации. При превышении этого ограничения репликация останавливается и слот репликации удаляется. Значение по умолчанию – 50 ГБ. -
serviceSchema
— имя схемы БД для служебных таблиц. -
objectTransferSettings
— настройки переноса схемы на первичной и финальной стадиях трансфера (значенияBEFORE_DATA
иAFTER_DATA
, соответственно).
Настройки переноса схемы при активации и деактивации трансфера
Примечание
Настройки эндпоинта для источника по умолчанию позволяют успешно выполнить трансфер для большинства баз данных. Изменяйте настройки первичной и финальной стадий переноса только если в этом есть необходимость.
В процессе работы трансфера схема базы данных переносится с источника на приемник. Перенос выполняется в два этапа:
-
На стадии активации.
Этот этап выполняется при активации трансфера перед копированием или репликацией для создания схемы на приемнике. Вы можете выбрать, какие части схемы будут перенесены. По умолчанию это
TABLE
,VIEW
,PRIMARY KEY
,SEQUENCE
,SEQUENCE OWNED BY
,RULE
,TYPE
,FUNCTION
,DEFAULT
. -
На стадии деактивации.
Эта стадия выполняется в конце работы трансфера, при его деактивации. Если трансфер постоянно работает в режиме репликации, то финальная стадия переноса будет выполнена только при остановке репликации. Вы можете выбрать, какие части схемы будут перенесены.
На финальной стадии предполагается, что при деактивации трансфера на источнике нет пишущей нагрузки. Это можно гарантировать переводом в режим
только чтение
(read-only). На этой стадии схема базы данных на приемнике приводится в состояние, когда она будет консистентна схеме на источнике.Рекомендуется включать в финальную стадию переноса ресурсоемкие операции, например, перенос индексов. Перенос индексов в начале трансфера может замедлить его работу.
Перенос схемы и на первичной, и на финальных стадиях выполняется с помощью утилитыpg_dump
.
Примечание
При редактировании настроек одного из эндпоинтов трансфера, который находится в состоянии Реплицируется, схемы таблиц на приемнике сохраняются. При этом на приемник переносятся только схемы таблиц, отсутствующих в приемнике на момент перезапуска трансфера.
Значения позиций в последовательности при репликации нельзя гарантированно сохранить, поэтому рекомендуется сделать обновление sequence
на приемнике.
Настройка приемника данных
Настройте один из поддерживаемых приемников данных:
- PostgreSQL;
- MySQL®;
- ClickHouse®;
- Greenplum®;
- Yandex Managed Service for YDB;
- Yandex Object Storage;
- Apache Kafka®;
- YDS;
- Elasticsearch;
- OpenSearch.
Полный список поддерживаемых источников и приемников в Yandex Data Transfer см. в разделе Доступные трансферы.
После настройки источника и приемника данных создайте и запустите трансфер.
Действия с базой данных во время трансфера
Совет
Протокол репликации 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
. -
Пересоздайте базу в приемнике.
Важно
Это приведет к потере всех данных в базе.