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

Чтение реплик в Базе данных Azure для PostgreSQL

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

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

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

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

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

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

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

Соображения

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

Замечание

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

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

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

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

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

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

Это важно

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

Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по предварительной версии:

  1. На каждую исходную реплику чтения можно создать до 5 реплик чтения с поддержкой 2 уровней репликации.
  2. Операция повышения уровня не поддерживается для промежуточных реплик чтения с каскадными репликами чтения.
  3. Виртуальные конечные точки не поддерживаются для каскадных реплик.
  4. Каскадные реплики чтения поддерживаются на промежуточных репликах с PostgreSQL версии 14 и выше.
  5. Эта функция поддерживается в: Западная часть США, Центральная Испания, Восточная Австралия, Центрально-Южная Часть США, Западная Часть Великобритании, Центральная Польша, Северная Италия, Западная часть США 2, Восточная Азия и Центральная Канада.

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

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

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

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

  • Подключение к экземпляру реплики: вы можете подключиться к реплике с его именем узла и допустимой учетной записью пользователя, как к обычному гибкому серверу в базе данных 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_activityON. Этот параметр является динамическим и не требует перезапуска экземпляра.
Логическая репликация
Показать имя Идентификатор метрики Единица Description Размерность Включена по умолчанию
Максимальная задержка логической репликации logical_replication_delay_in_bytes Bytes Максимальная задержка во всех слотах логической репликации. Не применяется Да
Replication
Показать имя Идентификатор метрики Единица Description Размерность Включена по умолчанию
Максимальная задержка физической репликации physical_replication_delay_in_bytes Bytes Максимальная задержка во всех асинхронных слотах физической репликации. Не применяется Да
Задержка чтения реплики physical_replication_delay_in_seconds Секунды Задержка чтения реплики в секундах. Не применяется Да

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

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

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

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

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

Замечание

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

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

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

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

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

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роль сервера Резервное копирование Разрешено восстановление
Primary Да Да
Реплика для чтения нет нет
Реплика для чтения повышена до уровня первичной базы данных Да Да

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

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

Нетворкинг

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

Это важно

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

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

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

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

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

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

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

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

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

Администраторы могут изменять параметры сервера на сервере реплики чтения и задавать значения, отличные от основного сервера. Единственным исключением является параметры, которые могут повлиять на восстановление реплики, упомянутые также в разделе "Масштабирование" ниже: 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

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

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

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

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

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

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

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

  • Last updated on