Чтение реплик в гибком сервере Базы данных Azure для PostgreSQL

Функция реплики чтения позволяет реплицировать данные с гибкого сервера База данных Azure для PostgreSQL на реплику только для чтения. Реплики обновляются асинхронно с помощью собственной технологии физической репликации ядра PostgreSQL. По умолчанию используется потоковая репликация с использованием слотов репликации. При необходимости для синхронизации используется перенос журналов на основе файлов. Вы можете реплицировать данные с главного сервера на несколько реплик (до пяти).

Реплики — это новые серверы, которыми вы управляете так же, как и обычным гибким сервером База данных Azure для PostgreSQL. Для каждой реплики чтения вы платите за выделенные вычислительные ресурсы в единицах vCore и за хранилище в ГБ в месяц.

Узнайте, как создать читаемую реплику.

Когда использовать реплики чтения

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

Типичным сценарием является использование реплики для чтения в качестве источника данных для рабочих нагрузок бизнес-аналитики и аналитики при создании отчетов.

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

Соображения

Реплики чтения предназначены в первую очередь для сценариев, когда перенос нагрузки запросов полезен, и небольшая задержка допустима. Они оптимизированы для предоставления обновлений, близких к реальному времени, с основного узла для большинства нагрузок, что делает их отличным решением для сценариев с преобладанием операций чтения. Однако важно отметить, что они не предназначены для синхронных сценариев репликации, требующих точности данных до минуты. Хотя данные реплики в конечном итоге становятся согласованными с первичной, может возникнуть задержка, которая обычно варьируется от нескольких секунд до минут, и в некоторых тяжелых рабочих нагрузках или сценариях высокой задержки эта задержка может продлиться до часов. Как правило, реплики чтения в том же регионе, что и основная реплика, имеют меньшую задержку, чем геореплики, поскольку последние часто подвержены задержкам, обусловленным географической удалённостью. Дополнительные сведения о последствиях георепликации в производительности см. в статье о георепликации . Данные на реплике в итоге становятся согласованными с данными на основном сервере. Используйте этот компонент только для таких рабочих нагрузок, которым не страшна такая задержка.

Создание реплики

Вы можете развернуть основной сервер База данных Azure для PostgreSQL — гибкий сервер в любом регионе, поддерживающем эту службу. Вы можете создавать реплики основного сервера в одном регионе или в разных глобальных Azure регионах, где доступно База данных Azure для PostgreSQL. Вы также можете создавать реплики в некоторых регионах Azure в суверенных облаках. Список независимых облачных регионов, где можно создавать реплики, см. в статье о георепликации .

При запуске процесса создания реплики создается пустой гибкий сервер База данных Azure для PostgreSQL. Новый сервер заполняется данными на основном сервере. При создании реплик в том же регионе используется метод на основе моментального снимка. Поэтому время создания не зависит от размера данных. Геореплики создаются с помощью базовой резервной копии первичной, которая затем передается по сети. Поэтому время создания может составлять от нескольких минут до нескольких часов в зависимости от исходного размера.

Реплика считается успешно созданной только при выполнении двух условий: вся резервная копия основного копируется в реплику, а журналы транзакций синхронизируются не более чем с задержкой в 1 ГБ.

Чтобы добиться успешной операции создания, избегайте выполнения реплик во время высокой загрузки транзакций. Например, не создавайте реплики при миграции из других источников на гибкий сервер База данных Azure для PostgreSQL или во время больших операций массовой загрузки. Если вы переносите данные или загружаете большие объемы данных, сначала завершите эту задачу. После завершения ее можно приступить к настройке реплик. После завершения операции миграции или массовой загрузки проверьте, возвращается ли размер журнала транзакций в обычный размер. Как правило, размер журнала транзакций должен быть близок к значению, определенному в параметре max_wal_size сервера. Хранилище журналов транзакций можно отслеживать с помощью используемой метрики хранилища журналов транзакций , которая предоставляет аналитические сведения о объеме хранилища, используемого журналом транзакций. Отслеживая эту метрику, можно убедиться, что размер журнала транзакций находится в ожидаемом диапазоне, и процесс создания реплики может начаться.

Узнайте, как создать реплику для чтения.

Управление конфигурацией

При настройке реплик чтения для гибкого сервера База данных Azure для PostgreSQL необходимо понять, какие конфигурации сервера можно настроить, какие конфигурации реплики наследуются от основного сервера и все связанные ограничения.

Унаследованные конфигурации

При создании реплики чтения он наследует определенные конфигурации сервера от основного сервера. Эти конфигурации можно изменить во время создания реплики или после настройки реплики. Однако реплика для чтения не наследует определённые параметры, такие как георезервное копирование, от основного сервера.

Конфигурации во время создания реплики

• Уровень, размер хранилища: для повышения уровня до операции сервера-источника уровень и размер хранилища должны соответствовать основному серверу. Для операции перевода в независимый сервер и удаления из репликации ценовая категория и размер хранилища могут соответствовать параметрам основного сервера или превышать их.
• Уровень производительности (IOPS): настраиваемый.
• Шифрование данных: можно изменить, включая переход с ключей, управляемых службой, на ключи, управляемые клиентом.

Конфигурации после создания

• Правила брандмауэра: можно добавлять, удалять или изменять правила.
• Уровень, размер хранилища: для повышения уровня до операции сервера-источника уровень и размер хранилища должны соответствовать основному серверу. Для операции перевода на независимый сервер и удаления из репликации ценовая категория и размер хранилища могут соответствовать параметрам основного сервера или превышать их.
• Уровень производительности (IOPS): настраиваемый.
• Настраиваемый метод аутентификации: параметры включают переход с проверки подлинности PostgreSQL на Microsoft Entra.
• Параметры: большинство параметров настраиваются. Однако параметры, влияющие на размер общей памяти, должны быть согласованы с основным сервером, особенно для сценариев возможного повышения до основного сервера. При выполнении операции перевода в независимый сервер и удаления из репликации эти параметры должны совпадать с параметрами на основном сервере или превышать их.
• Расписание обслуживания: настраиваемый.

Неподдерживаемые функции в репликах чтения

Первичные серверы поддерживают определенные функциональные возможности, которые невозможно настроить на репликах чтения. Сюда относятся следующие возможности.

• Резервные копии, включая георезервные копии.
• Высокий уровень доступности (HA).

Если исходный сервер База данных Azure для PostgreSQL Flexible Server зашифрован с использованием ключей, управляемых клиентом, см. документацию, чтобы учесть другие аспекты.

Создание каскадных реплик чтения

Каскадные реплики чтения могут помочь распределить рабочие нагрузки чтения, уменьшая нагрузку на основной сервер. Развертывание реплик чтения в разных регионах (межрегионные реплики чтения) может помочь распределить трафик чтения ближе к пользователям в различных регионах. Вы можете добавить каскадные реплики чтения на сервер База данных Azure для PostgreSQL. Эта функция позволяет создавать новые реплики чтения на основе существующей реплики чтения, при этом существующая реплика чтения служит источником для следующего уровня.

Первая реплика чтения асинхронно реплицирует данные с первичного сервера. Затем вы можете создать реплику чтения второго уровня, используя реплику первого уровня в качестве источника, тем самым образуя двухуровневую иерархию репликации. Эта архитектура повышает масштабируемость, позволяя использовать до 30 серверов-реплик для чтения: основной сервер поддерживает до пяти реплик для чтения, а каждая из этих реплик — ещё пять дополнительных реплик. Чтобы добавить каскадную реплику чтения для База данных Azure для PostgreSQL гибкого сервера, выберите существующую реплику чтения (созданную с первичного сервера), перейдите на вкладку "Репликация" и выберите "Создать реплику".

Например, основной сервер может иметь до пяти реплик для чтения (уровень 1). Одно из них, скажем read-replica-1, выступает в качестве источника для другой реплики read-replica-2 , которая становится частью (уровень 2).

Основные рекомендации

• Вы можете создать до пяти реплик чтения для каждой исходной реплики чтения при поддержке двух уровней репликации.
• Операция переключения поддерживает промежуточную реплику чтения (источник) и каскадную реплику чтения.
• Повышение уровня основной операции не поддерживает промежуточные реплики чтения с каскадными репликами чтения.
• Виртуальные конечные точки не поддерживаются для каскадных реплик.
• Каскадные реплики чтения поддерживаются на промежуточных репликах с PostgreSQL версии 14 и выше.

Подключение к реплике

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

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

Для подключения к реплике можно использовать два метода:

• Прямое подключение к реплике: Вы можете подключиться к реплике, используя её имя узла и действительную учётную запись пользователя, так же, как и к обычному гибкому серверу База данных Azure для PostgreSQL. Для сервера с именем myreplica с именем администратора myadmin можно подключиться к реплике с помощью psql:

psql -h myreplica.postgres.database.azure.com -U myadmin postgres

При появлении запроса введите пароль для учетной записи пользователя.

Чтобы упростить процесс подключения, портал Azure предоставляет готовые строки подключения. Эти строки подключения можно найти на странице "Подключение ". Они включают как libpq переменные, так и строки подключения, адаптированные для консолей bash.

• С помощью виртуальных конечных точек: альтернативный метод подключения использует виртуальные конечные точки. Дополнительные сведения см. в разделе "Виртуальные конечные точки". С помощью виртуальных конечных точек можно настроить конечную точку только для чтения, чтобы всегда указывать на реплику независимо от того, какой сервер в настоящее время содержит роль реплики.

Мониторинг репликации

Функция реплики чтения в База данных Azure для PostgreSQL зависит от механизма слотов репликации. Основное преимущество слотов репликации заключается в том, что они автоматически настраивают количество журналов транзакций (сегментов WAL), необходимых для всех серверов реплик. Эта корректировка помогает предотвратить рассинхронизацию реплик, поскольку позволяет не удалять сегменты WAL на основном сервере до того, как реплики их получат. Недостаток этого подхода заключается в риске нехватки места на основном сервере, если слот репликации остается неактивным в течение длительного времени. В таких ситуациях основной сервер накапливает WAL-файлы, что приводит к постепенному увеличению объёма используемого хранилища. Если использование хранилища достигает 95% или если доступная емкость меньше 5 ГиБ, сервер автоматически переключается в режим только для чтения, чтобы избежать ошибок, связанных с ситуациями с полным диском.
Таким образом, мониторинг задержки репликации и состояния слотов репликации имеет решающее значение для реплик чтения.

Задайте правила генерации оповещений для используемого хранилища или процента хранения, а также задержки репликации, если они превышают определенные пороговые значения, чтобы можно было заранее действовать, увеличивать размер хранилища и удалять отстающие реплики чтения. Например, можно задать оповещение, если процент хранения превышает 80 % использования, и если задержка реплики превышает 5 минут. Используемая метрика хранилища журналов транзакций показывает, является ли накопление файлов WAL основной причиной чрезмерного использования хранилища.

Мониторинг метрик

служба База данных Azure для PostgreSQL предоставляет следующие метрики для мониторинга репликации.

Вы можете использовать расширенные метрики для мониторинга и оповещений при репликации чтения.

Включение расширенных метрик

• Большинство этих новых метрик отключены по умолчанию. Хотя существует несколько исключений, которые включены по умолчанию. Самый правый столбец в следующих таблицах указывает, включена ли каждая метрика по умолчанию или нет.
• Чтобы включить эти метрики, которые не включены по умолчанию, задайте для параметра metrics.collector_database_activity значение ON. Этот параметр является динамическим и не требует перезапуска экземпляра.

Логическая репликация

Replication

Дополнительные сведения см. в руководстве по созданию копий для чтения.

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

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

Задайте оповещение, чтобы сообщить вам, когда задержка реплики достигает значения, недопустимого для рабочей нагрузки.

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

Состояние репликации

Чтобы отслеживать ход и состояние операции репликации и продвижения, обратитесь к столбцу Состояние репликации на портале Azure. Этот столбец находится на странице репликации и отображает различные состояния, которые предоставляют информацию о текущем состоянии реплик для чтения и их связи с основной. Для пользователей, зависящих от API Azure Resource Manager, при вызове API GetReplica состояние отображается как ReplicationState в контейнере свойств replica.

Возможные значения

Узнайте, как отслеживать репликацию.

Соображения

В этом разделе изложены основные моменты касательно функции "Чтение реплики". Следует учитывать следующие соображения.

• Операции питания. Вы можете применять операции питания, включая действия запуска и остановки , как к основным, так и к серверам реплик. Однако для сохранения целостности системы следуйте определенной последовательности. Прежде чем останавливать реплики чтения, сначала убедитесь, что первичный сервер остановлен. При выполнении операций запуска инициируйте действие запуска на серверах-репликах перед запуском основного сервера.
• Если у сервера есть реплики чтения, сначала удалите реплики чтения, а затем удалите первичный сервер.
• Обновление основной версии на месте для гибкого сервера База данных Azure для PostgreSQL требует удаления всех реплик для чтения и каскадных реплик для чтения, настроенных для этого сервера. После удаления реплик можно обновить основной сервер до требуемой основной версии. После завершения обновления можно повторно создать реплики, чтобы возобновить процесс репликации.
  • Сброс пароля администратора: сброс пароля администратора на сервере реплики в настоящее время не поддерживается. Кроме того, обновление пароля администратора вместе с продвижением операции реплики в том же запросе не поддерживается. Если вы хотите выполнить эти действия, сначала продвигайте сервер реплики, а затем обновите пароль на только что продвигаемом сервере отдельно.

Новые реплики

Вы создаёте реплику чтения как новый сервер База данных Azure для PostgreSQL — гибкий сервер. Вы не можете сделать существующий сервер в реплику.

Перемещение ресурсов

Реплики чтения можно создать в другой группе ресурсов, чем группа ресурсов основного сервера. Однако перемещение реплик чтения в другую группу ресурсов после их создания не поддерживается. Кроме того, перемещение реплик в другую подписку не поддерживается. Перемещение основного ресурса, у которого есть реплики для чтения, в другую группу ресурсов или подписку не поддерживается.

Автоматическое увеличение хранилища

При настройке реплик чтения для гибкого сервера База данных Azure для PostgreSQL убедитесь, что параметр автоматического увеличения хранилища на репликах совпадает с параметром основного сервера. Функция автоматического увеличения хранилища позволяет хранилищу базы данных автоматически увеличиваться, чтобы предотвратить отсутствие места, что может привести к сбоям базы данных. Вот как эффективно управлять параметрами автоматического увеличения хранилища:

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

Резервное копирование и восстановление

При управлении резервными копиями и восстановлением для База данных Azure для PostgreSQL гибкого сервера следует учитывать текущую и предыдущую роль сервера в различных сценариях повышения уровня. Помните следующие ключевые моменты:

Повышение уровня до основного сервера

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

Для ясности в следующей таблице показаны следующие моменты:

Перевести на независимый сервер и удалить из репликации

Пока сервер является репликой для чтения, система не создает резервные копии. Однако после того, как вы переводите его в статус самостоятельного сервера, система создаёт резервные копии и для этого сервера, и для основного сервера. Резервные копии можно восстановить на обоих серверах.

Нетворкинг

Реплики чтения поддерживают все сетевые параметры, которые поддерживаются База данных Azure для PostgreSQL гибким сервером.

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

Дополнительные сведения о том, как настроить закрытый доступ (интеграцию с виртуальной сетью) для реплик чтения и понять последствия репликации между регионами Azure и виртуальными сетями в среде частной сети, см. в статье Репликация между регионами Azure и виртуальными сетями при использовании частной сети.

Устранение проблем со слотом репликации

В редких случаях высокая задержка, вызванная слотами репликации, может привести к увеличению использования хранилища на основном сервере из-за скапливающихся WAL-файлов. Если использование хранилища достигает 95 % или доступная емкость ниже 5 ГиБ, сервер автоматически переключается на режим только для чтения, чтобы предотвратить ошибки с полным диском.

Поддержание работоспособности и функциональности основного сервера является приоритетом. В таких пограничных случаях сервер может удалить слот репликации, чтобы убедиться, что основной сервер остается рабочим для чтения и записи трафика. Таким образом, репликация переключается на режим доставки журналов на основе файлов, что может привести к более высокой задержке репликации.

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

Parameters

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

Администраторы могут изменять параметры на сервере реплики чтения и задавать значения, отличные от основного сервера. Единственным исключением является параметры, которые могут повлиять на восстановление реплики, упомянутые также в разделе "Масштабирование" ниже: max_connections, , max_prepared_transactionsmax_locks_per_transaction, . max_wal_sendersmax_worker_processes Чтобы обеспечить простое восстановление реплики чтения, и она не сталкивается с ограничениями общей памяти, всегда задайте для этих параметров значения, которые эквивалентны или больше, чем те, которые настроены на основном сервере. Прежде чем уменьшить значения параметров на сервере-реплике для чтения, убедитесь, что задержка репликации минимальна или реплика полностью догнала основной сервер, чтобы избежать потенциальных проблем с репликацией или восстановлением.

Scale

Вы можете увеличить и уменьшить масштаб вычислительных ресурсов (виртуальных ядер), изменить уровень служб с общего назначения на оптимизированную для памяти (или наоборот) и увеличить масштаб хранилища. Однако применяются следующие предостережения.

Для масштабирования вычислений:

• Служба База данных Azure для PostgreSQL требует, чтобы несколько параметров на репликах были больше или равны параметрам на основном сервере, чтобы удостовериться, что реплика не исчерпывает общую память во время восстановления. Затронутые параметры: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

• Масштабирование: сначала увеличьте вычислительные ресурсы реплики, а затем — первичного узла.

• Уменьшение масштаба: сначала уменьшите масштаб вычислительных ресурсов основного узла, а затем — реплики.

• Вычисления на основном сервере всегда должны быть равными или меньше, чем вычислительные ресурсы на наименьшей реплике.

Для масштабирования хранилища:

• Масштабирование: сначала масштабируйте хранилище реплики, а затем масштабируйте основной объект.

• Размер хранилища на основном сервере всегда должен быть равен или меньше размера хранилища на наименьшей реплике.

Связанный контент

• Гео-репликация в База данных Azure для PostgreSQL.
• Повышение реплик чтения в База данных Azure для PostgreSQL.
• Виртуальные конечные точки для реплик чтения в базе данных Azure для PostgreSQL.
• Создайте реплику для чтения.
• Репликация в регионах Azure и виртуальных сетях с приватными сетями.