Поделиться через

Реплики чтения в Базе данных Azure для PostgreSQL (гибкий сервер)

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Внимание

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

Некоторые функциональные возможности ограничены основными серверами и не могут быть настроены на репликах чтения. Например:

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

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

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

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

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

Существует два метода подключения к реплике:

  • Непосредственно к экземпляру реплики: вы можете подключиться к реплике с помощью имени узла и допустимой учетной записи пользователя, так как в обычном База данных 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 гибкий сервер предоставляет две метрики для мониторинга репликации. Две метрики : Максимальная физическая задержка репликации и задержка чтения реплики. Сведения о том, как их просмотреть, см. в разделе о мониторинге реплики статьи с инструкциями по работе с репликами чтения.

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

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

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

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

Примечание.

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

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

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

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

Состояние репликации Description Повышение порядка Порядок создания реплики чтения
Перенастройки Ожидание начала реплики-первичной ссылки. Это может оставаться дольше, если реплика или регион недоступны, например из-за аварии. 1 Н/П
Подготовка Реплика чтения подготавливается и репликация между двумя серверами еще не запущена. Пока подготовка не завершится, вы не сможете подключиться к реплике чтения. Н/П 1
Обновление Конфигурация сервера находится под подготовкой после триггерного действия, например повышение или создание реплики чтения. 2 2
Кетчуп Файлы WAL применяются к реплике. Длительность этого этапа во время повышения зависит от выбранного параметра синхронизации данных — запланированного или принудительного. 3 3
Активный Работоспособное состояние, указывающее, что реплика чтения успешно подключена к первичной. Если серверы остановлены, но были успешно подключены раньше, состояние остается активным. 4 4
Разбитый Неработоспособное состояние, указывающее на сбой операции повышения, или реплика не может подключиться к первичной по какой-то причине. Удалите реплику и повторно создайте реплику, чтобы устранить эту проблему". Неприменимо Неприменимо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Сохранение прошлых резервных копий: если сервер был основным и имеет резервные копии в течение этого периода, эти резервные копии сохраняются. Они будут храниться до определяемого пользователем срока хранения.

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

Для ясности вот таблица, иллюстрирующая следующие моменты:

Роль сервера Резервное копирование Разрешено восстановление
Основной Да Да
Реплика чтения No No
Реплика чтения, повышенная до первичной Да Да

Повышение уровня независимого сервера и удаление из репликации

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

Сеть

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

Внимание

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

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

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

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

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

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

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

Параметры сервера

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

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

Масштабировать

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

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

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

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

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

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

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

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

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

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