Реплики чтения в Базе данных Azure для PostgreSQL — отдельный сервер

Область применения: отдельный сервер Базы данных Azure для PostgreSQL

Важно!

База данных Azure для PostgreSQL — один сервер находится на пути прекращения поддержки. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о переходе на База данных Azure для PostgreSQL — гибкий сервер см. в статье Что происходит с База данных Azure для PostgreSQL отдельным сервером?

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

Реплики — это новые серверы, которыми вы управляете как обычными серверами службы "База данных Azure для PostgreSQL". За каждую реплику чтения выставляется счет с учетом подготовленных вычислительных ресурсов (количество виртуальных ядер) и хранилища (ГБ/месяц).

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

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

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

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

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

Рекомендации

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

Примечание

Для большинства рабочих нагрузок реплики чтения обеспечивают обновление с главного сервера практически в реальном времени. Однако для постоянных рабочих нагрузок главного сервера с высокой интенсивностью записи задержка репликации может продолжать расти, в результате чего репликация всегда будет отставать от главного сервера. При этом также может увеличиться использование хранилища на главном сервере, так как файлы WAL не удаляются до тех пор, пока они не будут получены репликой. В случае повторения этой ситуации можно удалить и повторно создать реплику чтения после завершения рабочих нагрузок с большим объемом операций записи, чтобы восстановить надлежащее состояние реплики с точки зрения задержки. Асинхронные реплики чтения не подходят для таких рабочих нагрузок с большим объемом операций записи. При оценке реплик чтения для приложения отслеживайте задержку в реплике в течение всего цикла рабочей нагрузки приложения (как в пиковое, а так и в непиковое время), чтобы получить данные о возможной задержке и ожидаемых значениях RTO/RPO в различных точках цикла рабочей нагрузки.

Примечание

Автоматическое резервное копирование выполняется для серверов реплик с хранилищем до 4 ТБ.

Репликация между регионами

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

Примечание

Серверы уровня "Базовый" поддерживают только репликацию одного региона.

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

Регионы для реплики чтения

Универсальные регионы реплики

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

"Восточная Австралия", "Юго-Восточная Австралия", "Южная Бразилия", "Центральная Канада", "Восточная Канада", "Центральная часть США", "Восточная Азия", "Восточная часть США", "Восточная часть США 2", "Восточная Япония", "Западная Япония", "Республика Корея, центральный регион", "Республика Корея, южный регион", "Центрально-северная часть США", "Северная Европа", "Центрально-южная часть США", "Юго-Восточная Азия", "Южная часть Соединенного Королевства", "Западная часть Соединенного Королевства", "Западная Европа", "Западная часть США", "Западная часть США 2", "Центрально-западная часть США".

Пары регионов

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

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

Но есть и некоторые ограничения:

  • Однонаправленные пары. Некоторые регионы Azure считаются парными только в одном направлении. К ним относятся: "Западная Индия", "Южная Бразилия". Это означает, что для размещенного в Западной Индии главного сервера можно создать реплику в Южной Индии, но для размещенного в Южной Индии главного сервера нельзя создать реплику в Западной Индии. Это связано с тем, что для региона "Западная Индия" дополнительным регионом является "Южная Индия", но для региона "Южная Индия" дополнительный регион отличается от региона "Западная Индия".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метрика Задержка реплики показывает время с момента последнего воспроизведения транзакций. Если на главном сервере не выполняются транзакции, метрика будет отображать соответствующее время задержки. Эта метрика применима и доступна только для серверов-реплик. Задержка реплики вычисляется из представления pg_stat_wal_receiver:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

Настройте отправку предупреждений о достижении недопустимого для вашей рабочей нагрузки значения задержки реплики.

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

Примечание

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

Завершение репликации или повышение уровня реплики

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

Примечание

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

Рекомендации

  • Прежде чем останавливать репликацию в реплике чтения, проверьте задержку репликации, чтобы убедиться, что реплика содержит все необходимые данные.
  • Так как реплика чтения должна применить все ожидающие применения журналы, прежде чем она сможет стать автономным сервером, RTO для рабочих нагрузок с высокой интенсивностью записи может оказаться выше при остановке репликации, так как в реплике может возникнуть значительная задержка. Обратите внимание на это при планировании повышения уровня реплики.
  • Сервер, образовавшийся в результате повышения уровня реплики, нельзя снова преобразовать в реплику.
  • Если уровень реплики был повышен до главного сервера, восстановить репликацию на предыдущий главный сервер будет нельзя. Чтобы вернуться на предыдущий главный сервер, можно либо установить новый сервер реплики с новым названием и/или удалить предыдущий главный сервер и создать реплику под его именем.
  • Если у вас есть несколько реплик чтения, то при повышении уровня одной из них до главного сервера другие серверы реплик останутся подключены к старому главному серверу. Возможно, потребуется повторно создать реплики на новом главном сервере (реплике, уровень которой был повышен).

Если остановить репликацию на определенную реплику, она потеряет все соединения с предыдущим главным сервером и другими репликами.

Процесс остановки репликации описан в этой статье.

Отработка отказа на реплику

В случае сбоя главного сервера отработка отказа на реплику чтения автоматически не производится.

Так как репликация является асинхронной, между главным сервером и репликой может возникнуть большая задержка. На размер задержки влияет ряд факторов, таких как тип рабочей нагрузки, выполняемой на главном сервере, и задержка между главным сервером и репликой. В типичных случаях с рабочей нагрузкой с номинальной интенсивностью записи ожидаемая задержка реплики составляет от нескольких секунд до нескольких минут. Однако в случаях, когда на главном сервере запущена рабочая нагрузка с высокой интенсивностью записи, а реплика недостаточно быстро "нагоняет" главный сервер, задержка может быть значительно выше. Вы можете отслеживать задержку репликации с помощью метрики Задержка реплики. Метрика задержки реплики отражает время с момента последнего воспроизведения транзакций на этой реплике. Мы рекомендуем определять среднюю задержку, наблюдая за задержкой реплики в течение определенного времени. Вы можете настроить оповещение о задержке реплики, чтобы можно было принять меры, если задержка выйдет за пределы ожидаемого диапазона.

Совет

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

После того как вы решили выполнить отработку отказа в реплике:

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

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

Если ваше приложение успешно обрабатывает операции чтения и записи, значит, отработка отказа выполнена. Время простоя вашего приложения зависит от того, когда обнаружится ошибка и будут выполнены шаги 1 и 2, описанные выше.

Аварийное восстановление

При возникновении серьезных аварийных событий, таких как сбои на уровне зоны доступности или региона, можно выполнить аварийное восстановление, повысив уровень реплики чтения. На портале пользовательского интерфейса перейдите к серверу реплики чтения. Затем откройте вкладку "Репликация", где можно остановить работу реплики и повысить ее уровень до независимого сервера. Кроме того, остановить сервер реплики и повысить его уровень можно с помощью Azure CLI.

Рекомендации

В этом разделе приведены рекомендации по использованию компонента "Реплика чтения".

Предварительные требования

Реплики чтения и функция логического декодирования используют для получения сведений журнал с упреждающей записью (WAL) Postgres. Для этих двух функций требуются разные уровни ведения журнала от Postgres. Логическому декодированию нужен более высокий уровень ведения журнала, чем репликам чтения.

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

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

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

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

Конфигурация реплики

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

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

Масштабирование

Масштабирование виртуальных ядер между уровнями "Общего назначения" и "Оптимизировано для операций в памяти"

  • Для PostgreSQL параметр max_connections на сервере-получателе должен быть не меньше соответствующего значения на главном сервере, иначе сервер-получатель не запустится.
  • В Базе данных Azure для PostgreSQL максимально допустимое количество подключений для каждого сервера привязано к SKU вычислительного ресурса, так как соединения занимают память. Вы можете узнать больше о связи между значениями max_connections и номерами SKU.
  • Вертикальное увеличение масштаба: сначала увеличьте масштаб вычислительных ресурсов реплики, а затем — главного сервера. Эта последовательность позволяет избежать нарушения требования max_connections.
  • Вертикальное уменьшение масштаба: сначала уменьшите масштаб вычислительных ресурсов главного сервера, а затем — реплики. Если масштабировать реплику до уровня ниже уровня главного сервера, возникнет ошибка, так как это нарушает требование max_connections.

Масштабирование хранилища

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

Уровень Basic

Серверы уровня "Базовый" поддерживают только репликацию одного региона.

max_prepared_transactions

Для PostgreSQL требуется, чтобы значение параметра max_prepared_transactions реплики чтения было не меньше соответствующего значения главного сервера. В противном случае реплика не запустится. Если нужно изменить значения параметра max_prepared_transactions на главном сервере, сначала измените его на репликах.

Остановленные реплики

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

Удаленные главный сервер и отдельные серверы

При удалении главного сервера все его реплики чтения становятся отдельными серверами. Чтобы применить такое изменение конфигурации, реплики будут перезапущены.

Дальнейшие действия