Skip to main content
Реплики для чтения позволяют создать одну или несколько копий вашей основной базы данных Managed Postgres. Эти реплики постоянно синхронизируются с основной базой данных с помощью встроенной репликации PostgreSQL, чтобы отражать все изменения. Чтобы управлять репликами для чтения, нажмите значок редактирования в вашем хранилище: Откроется диалоговое окно хранилища, где можно просмотреть существующие сервисы и создать новые реплики для чтения:

​
Управление репликами для чтения

Страница Реплики для чтения предлагает два представления, между которыми можно переключаться с помощью элементов управления Flow и Table в правом верхнем углу. Представление Flow показывает топологию репликации: вверху находится основной экземпляр, а от него вниз к каждой подключенной реплике идут стрелки, так что вы сразу видите уровень, регион и статус: Представление Table показывает список всех реплик с указанием Service name, облачного провайдера и региона, статуса сервиса, времени создания и действием Detach service: Чтобы создать новую реплику, нажмите Create read replica в правом верхнем углу любого из представлений.

​
Зачем нужны реплики для чтения

​
Масштабируемость

Реплики для чтения позволяют горизонтально масштабировать базу данных, распределяя рабочие нагрузки с интенсивным чтением между несколькими выделенными инстансами. Это особенно полезно для отчетных запросов, аналитических задач и панелей мониторинга в реальном времени, которые в противном случае конкурировали бы за ресурсы с продакшн-трафиком.

​
Изоляция

Направляя аналитические запросы и запросы бизнес-аналитики на реплики для чтения, вы разгружаете основной экземпляр, чтобы он оставался производительным и отзывчивым для операций записи и критически важных транзакционных рабочих нагрузок. Такое разделение повышает общую производительность и предсказуемость системы. Это также означает, что вам не нужно предоставлять аналитическим инструментам или средствам отчетности доступ на запись — они могут безопасно работать с репликой без риска случайного изменения данных.

​
Непрерывность бизнеса

Реплики для чтения могут играть важную роль в аварийном восстановлении. Если ваша основная база данных выйдет из строя, реплику для чтения можно перевести в роль основной, сведя к минимуму время простоя и потерю данных. Это обеспечивает дополнительный уровень отказоустойчивости помимо резервных узлов Высокой доступности.

​
Как работают реплики для чтения

В Managed Postgres реплики для чтения используют архитектуру WAL shipping, а не потоковую репликацию. Такое решение позволяет свести к минимуму влияние на основную базу данных.

​
WAL shipping из объектного хранилища

Когда ваша основная база данных обрабатывает транзакции, она генерирует записи журнала Write-Ahead Log (WAL). Эти сегменты WAL непрерывно архивируются в объектное хранилище (S3). Реплики для чтения получают и воспроизводят эти сегменты WAL из объектного хранилища, чтобы оставаться синхронизированными с основной базой. Эта архитектура отличается от резервных узлов высокой доступности, которые используют потоковую репликацию с прямым подключением к основной базе.

​
Почему мы выбрали этот подход

Мы намеренно спроектировали реплики для чтения так, чтобы они получали WAL из объектного хранилища, а не подключались напрямую к основному узлу как потоковые standby-реплики. Такой подход обеспечивает полную изоляцию между репликами для чтения и основной базой данных:
  • Нулевые накладные расходы на репликацию для основного узла: Реплики для чтения не поддерживают потоковые соединения с основным узлом, поэтому не создают никакой дополнительной нагрузки на CPU, память или сеть для ваших критически важных рабочих нагрузок.
  • Независимое масштабирование: Вы можете добавлять или удалять реплики для чтения без какого-либо влияния на производительность основного узла.
  • Сетевая изоляция: Реплики для чтения работают в собственной сетевой среде с отдельными конечными точками подключения.

​
Характеристики задержки репликации

Компромисс такого архитектурного решения — задержка репликации. Сегменты WAL архивируются с основного узла через равные промежутки времени (обычно каждые 60 секунд или при заполнении сегмента — в зависимости от того, что произойдёт раньше). Это означает, что в обычных условиях реплики для чтения могут отставать от основного узла на несколько десятков секунд. Для большинства сценариев масштабирования чтения — отчётности, аналитики, панелей мониторинга — такая задержка приемлема. Если вашему приложению требуется чтение почти в реальном времени, подумайте, можно ли направлять запросы на основной узел или устроит ли вас согласованность в конечном счёте в пределах этого окна.
Последнее изменение 12 июня 2026 г.