Бөлісу құралы:


Репликация и отправка серверов

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_slot_wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальный размер WAL, который может быть зарезервирован слотами репликации.
Тип данных integer
Default value -1
Допустимые значения -1
Тип параметра только для чтения
Документация max_slot_wal_keep_size

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 400
Допустимые значения 400
Тип параметра только для чтения
Документация wal_keep_size

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_slot_wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальный размер WAL, который может быть зарезервирован слотами репликации.
Тип данных integer
Default value -1
Допустимые значения -1
Тип параметра только для чтения
Документация max_slot_wal_keep_size

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 400
Допустимые значения 400
Тип параметра только для чтения
Документация wal_keep_size

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_slot_wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальный размер WAL, который может быть зарезервирован слотами репликации.
Тип данных integer
Default value -1
Допустимые значения -1
Тип параметра только для чтения
Документация max_slot_wal_keep_size

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 400
Допустимые значения 400
Тип параметра только для чтения
Документация wal_keep_size

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_slot_wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальный размер WAL, который может быть зарезервирован слотами репликации.
Тип данных integer
Default value -1
Допустимые значения -1
Тип параметра только для чтения
Документация max_slot_wal_keep_size

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 400
Допустимые значения 400
Тип параметра только для чтения
Документация wal_keep_size

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_slot_wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальный размер WAL, который может быть зарезервирован слотами репликации.
Тип данных integer
Default value -1
Допустимые значения -1
Тип параметра только для чтения
Документация max_slot_wal_keep_size

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_size

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 400
Допустимые значения 400
Тип параметра только для чтения
Документация wal_keep_size

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_segments

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает количество файлов WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 25
Допустимые значения 25
Тип параметра только для чтения
Документация

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout

max_replication_slots

Атрибут Значение
Категория Репликация и отправка серверов
Description Указывает максимальное количество слотов репликации, которые может поддерживать сервер.
Тип данных integer
Default value 10
Допустимые значения 2-262143
Тип параметра static
Документация max_replication_slots

max_wal_senders

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное число одновременно выполняющихся процессов отправителя WAL.
Тип данных integer
Default value 10
Допустимые значения 5-100
Тип параметра static
Документация max_wal_senders

Заметки, относящиеся к Azure

Значение по умолчанию для max_wal_senders набора параметров сервера при подготовке экземпляра База данных Azure для PostgreSQL гибкого сервера никогда не должно быть уменьшено ниже2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

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

  • Логическая репликация большого количества таблиц не обязательно требует большого количества отправителей WAL.
  • Единственная причина, по которой требуется отдельный отправитель WAL для каждой таблицы или группы таблиц, заключается в том, что вам нужны отдельные подписки для каждой из этих таблиц или групп.
  • Независимо от количества отправителей WAL, которые используются для физической и логической репликации, все они становятся активными одновременно, когда любая серверная часть записывает что-то в журнал перед записью. Когда это произойдет, отправителем WAL, назначенным для выполнения логической репликации, все просыпаются:
    1. Декодирование всех новых записей в WAL,
    2. Отфильтровать записи журнала, которые они не заинтересованы,
    3. Реплицируйте данные, относящиеся к каждому из них.
  • Отправители WAL похожи на подключения в том смысле, что, если они неактивны, это не имеет значения, сколько. Тем не менее, если они активны, они просто будут конкурировать за те же ресурсы, и производительность может в конечном итоге быть ужасно плохой. Это особенно верно для отправителей с логической репликацией, так как логическое декодирование довольно дорого. Каждый работник должен декодировать весь WAL, даже если он реплицирует только операции, влияющие на одну таблицу, и это представляет крошечный процент всех данных в журнале перед записью. Для физической репликации это не так важно, так как отправители WAL не используют ЦП так интенсивно, и они, как правило, привязаны к пропускной способности сети в первую очередь.
  • Таким образом, в целом лучше не иметь больше отправителей WAL, чем виртуальные ядра.
  • Рекомендуется добавить место для нескольких дополнительных отправителей WAL, чтобы обеспечить будущий рост или временные всплески подключений к репликации. Ниже приведены два примера, которые помогут проиллюстрировать его лучше.
    • Для сервера с 8 виртуальными ядрами, высокой доступности отключены, 2 реплики чтения и 3 слота логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокой доступности (0) + физические слоты для реплик чтения (2) + логические слоты (3) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (1) = 6.
    • Для сервера с 16 виртуальными ядрами, включенной высокой доступности, 4 реплики чтения и 5 слотов логической репликации, может потребоваться настроить max_wal_senders как сумму физических слотов для высокого уровня доступности (2) + физические слоты для реплик чтения (4) + логические слоты (5) + некоторые дополнительные для будущего роста, учитывая доступные виртуальные ядра (2) = 13.
  • Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.

track_commit_timestamp

Атрибут Значение
Категория Репликация и отправка серверов
Description Собирает время фиксации транзакции.
Тип данных boolean
Default value off
Допустимые значения on,off
Тип параметра static
Документация track_commit_timestamp

wal_keep_segments

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает количество файлов WAL, удерживаемых для резервных серверов.
Тип данных integer
Default value 25
Допустимые значения 25
Тип параметра только для чтения
Документация

wal_sender_timeout

Атрибут Значение
Категория Репликация и отправка серверов
Description Задает максимальное время ожидания репликации WAL.
Тип данных integer
Default value 60000
Допустимые значения 60000
Тип параметра только для чтения
Документация wal_sender_timeout