Реплики для чтения

Реплики для чтения позволяют создать одну или несколько копий вашей основной базы данных ClickHouse Managed Postgres. Эти реплики постоянно синхронизируются с основной базой данных с помощью встроенной репликации PostgreSQL, чтобы отражать все изменения.

Чтобы управлять репликами для чтения, нажмите значок редактирования в вашем хранилище:

Откроется диалоговое окно хранилища, где можно просмотреть существующие сервисы и создать новые реплики для чтения:

Страница Реплики для чтения предлагает два представления, между которыми можно переключаться с помощью элементов управления Flow и Table в правом верхнем углу.

Представление Flow показывает топологию репликации: вверху находится основной экземпляр, а от него вниз к каждой подключенной реплике идут стрелки, так что вы сразу видите уровень, регион и status:

Представление Table показывает список всех реплик с указанием Service name, облачного провайдера и региона, статуса сервиса, времени создания и действием Detach service:

Чтобы создать новую реплику, нажмите Create read replica в правом верхнем углу любого из представлений.

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

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

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

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

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

Эта архитектура отличается от резервных узлов высокой доступности, которые используют потоковую репликацию с прямым подключением к основной базе.

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

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

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

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