> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Миграция из Neon в ClickHouse Managed Postgres > Узнайте, как перенести данные PostgreSQL из Neon в ClickHouse Managed Postgres ClickHouse Managed Postgres включает ClickPipes — полностью управляемый способ онлайн-миграции из Neon. Он автоматически переносит схему, выполняет оптимизированную первоначальную загрузку с параллельным снятием снимков и использует фиксацию изменений данных (CDC), чтобы поддерживать обе базы данных синхронизированными вплоть до переключения. С помощью ClickPipes можно перенести многотерабайтные базы данных Postgres всего за несколько часов. Создайте отдельного пользователя ClickPipes с разрешениями на чтение и репликацию: ```sql theme={null} CREATE USER clickpipes_user PASSWORD ''; GRANT USAGE ON SCHEMA public TO clickpipes_user; GRANT SELECT ON ALL TABLES IN SCHEMA public TO clickpipes_user; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO clickpipes_user; ALTER USER clickpipes_user WITH REPLICATION; ``` Выполните эти шаги на продакшн-ветке Neon, повторив выдачу grant для каждой схемы, которую требуется перенести. Каждая реплицируемая таблица должна иметь primary key или использовать `REPLICA IDENTITY FULL`. В консоли Neon перейдите в **Settings → Logical Replication** и включите логическую репликацию. Если вы используете ограничения по IP, разрешите статические IP-адреса ClickPipes. Подробные инструкции см. в [руководстве по настройке источника Neon](/ru/integrations/clickpipes/postgres/source/neon-postgres). Следуйте [руководству по миграции с ClickPipes](/ru/products/managed-postgres/migrations/clickpipes), чтобы настроить и завершить миграцию. ClickPipes автоматизирует весь процесс от начала до конца: * Переносит исходную схему в пустую целевую базу данных. * Выполняет оптимизированную первоначальную загрузку с параллельным снятием снимков. * Использует CDC для поддержания синхронизации целевой базы с Neon. * Предоставляет мониторинг прогресса, задержки репликации и ошибок. * Проводит вас через проверку и переключение. Когда первоначальная загрузка завершена, а задержка репликации близка к нулю, выполните переключение с помощью пошаговой вкладки **Post-migration steps** в детальном представлении ClickPipe. Полное описание см. в разделе [Переключение трафика](/ru/products/managed-postgres/migrations/clickpipes#cutover). Мастер последовательно проведёт вас по шагам: 1. Переведите Neon в режим только для чтения, чтобы остановить запись. 2. Сверьте количество строк в источнике и целевой базе. 3. Приостановите пайп. 4. Сбросьте последовательности в целевой базе. 5. Переключите трафик, обновив connection string приложения так, чтобы он указывал на ClickHouse Managed Postgres. 6. Выполните очистку: удалите слот репликации и ClickPipe. Оставьте Neon доступным в режиме только для чтения на некоторое время — на случай, если потребуется откат. Когда новое окружение стабилизируется, выполните шаг очистки, чтобы удалить ClickPipe и его слот репликации.

Что учесть при миграции

Ветки

Neon предоставляет мгновенное ветвление по принципу copy-on-write. ClickHouse Managed Postgres использует локальное NVMe-хранилище, что обеспечивает быструю, предсказуемую и надёжную работу Postgres. Обратная сторона в том, что ветки создаются не мгновенно: они разворачиваются как независимые развёртывания с помощью [восстановления на определённый момент времени (PITR)](/ru/products/managed-postgres/backup-and-restore). Обычно они становятся доступны в течение нескольких минут. Для повседневной разработки мы рекомендуем держать небольшую базу данных ClickHouse Managed Postgres для разработки с репрезентативными обезличенными продакшн-данными — например, объёмом в несколько гигабайт — и создавать из неё PITR-ветки по мере необходимости. Создание и удаление веток можно автоматизировать с помощью [clickhousectl](/ru/concepts/features/interfaces/cli), нашего официального CLI, либо через [OpenAPI](/ru/products/managed-postgres/openapi) или [Terraform](/ru/products/managed-postgres/terraform) Некоторые клиенты используют этот подход для управления сотнями сред разработки. Мы активно улучшаем работу с форками и песочницами. См. [документацию по ветвлению](/ru/products/managed-postgres/branching).

Neon Serverless Driver

Если ваше приложение не использует Neon Serverless Driver, этот раздел можно пропустить. Приложения, работающие на платформах вроде [Vercel](https://vercel.com/docs), **могут** использовать [Neon Serverless Driver](https://neon.com/docs/serverless/serverless-driver) — драйвер на основе WebSocket, рассчитанный именно на Neon. Его нельзя просто перенаправить на ClickHouse Managed Postgres. Перед миграцией: * Проверьте наличие зависимостей, таких как [@neondatabase/serverless](https://www.npmjs.com/package/@neondatabase/serverless). Если они есть, замените их стандартным драйвером Postgres, например [node-postgres (pg)](https://node-postgres.com/). * Для serverless-нагрузок, создающих множество короткоживущих соединений, используйте [встроенный экземпляр PgBouncer](/ru/products/managed-postgres/connection#pgbouncer). * Подготовленные операторы поддерживаются. Однако, поскольку PgBouncer использует пулинг на уровне транзакций, проверьте приложения, которые полагаются на поведение уровня сеанса, — в большинстве приложений это встречается редко: 1. Используйте `SET LOCAL` вместо `SET` или `RESET` уровня сеанса. 2. Используйте временные таблицы в области транзакции с `ON COMMIT DROP`. 3. `NOTIFY` поддерживается, `LISTEN` — нет. 4. Используйте рекомендательные блокировки уровня транзакции, а не уровня сеанса. 5. Курсоры в области транзакции поддерживаются, `WITH HOLD` — нет. * Если ваше приложение зависит от неподдерживаемого поведения уровня сеанса, подключайтесь к Postgres напрямую, минуя PgBouncer. Подробнее см. [матрицу совместимости PgBouncer](https://www.pgbouncer.org/features.html).

Ограничения на количество соединений

ClickHouse Managed Postgres по умолчанию поддерживает 500 прямых соединений с Postgres. Если ваша рабочая нагрузка в Neon превышает это значение, вы можете: * Использовать пул соединений на стороне приложения. * Использовать входящий в комплект экземпляр PgBouncer, который поддерживает до 5 000 клиентских соединений. * Увеличить `max_connections`, если требуется больше прямых соединений. * Значение `max_connections` можно изменить в разделе **Settings → Edit parameters**. Некоторые изменения вступают в силу только после перезапуска. См. [документацию по конфигурации](/ru/products/managed-postgres/settings#changing-configuration).

Изменения схемы во время миграции

Промежуток между запуском ClickPipes и переключением должен быть максимально коротким — в идеале не более нескольких дней — и в течение этого периода следует избегать изменений схемы. Некоторые клиенты несколько дней поддерживают параллельные среды, тестируя свои приложения на ClickHouse Managed Postgres. По завершении тестирования они запускают новый ClickPipe для финальной миграции, тем самым сокращая время между первоначальной загрузкой и переключением. CDC реплицирует вставки, обновления, удаления и `ADD COLUMN`, однако большинство прочих изменений DDL не распространяются. Это касается индексов, триггеров, изменений enum, ограничений (constraints), функций и большинства модификаций столбцов. Некоторые изменения, например отсутствующее значение enum, приводят к остановке репликации и попадают в журналы ClickPipes. Внесите недостающее изменение в целевой системе — после этого репликация должна возобновиться. Другие изменения, такие как вновь созданный индекс или триггер, могут не прерывать CDC, но их всё равно необходимо создать вручную до переключения. Прежде чем переключать трафик, сравните схемы источника и целевой системы, создайте отсутствующие объекты и сбросьте последовательности. В [FAQ по миграции](/ru/products/managed-postgres/migrations/faq) описаны распространённые ошибки и способы их устранения.