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

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

max_slot_wal_keep_size

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_size

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_segments

wal_sender_timeout

max_replication_slots

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

Значение по умолчанию для max_replication_slots параметра — 10. Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_replication_slots , чтобы обеспечить правильную работу с высоким уровнем доступности.

Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_replication_slots на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_replication_slot. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.

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.
  • Если вы включите высокий уровень доступности, вам потребуется не менее 4 max_wal_senders , чтобы обеспечить правильную работу с высоким уровнем доступности. Для сервера с поддержкой высокой доступности, а также 5 реплик чтения и 12 слотов логической репликации, может потребоваться установить max_wal_senders на значение 21. Это связано с тем, что для каждой реплики чтения и каждого слота логической репликации требуется один max_wal_senders. Поэтому для этого требуется всего 1 (слот) * 5 (реплики чтения) + 12 (слоты логической репликации) + 4 (для правильной работы высокой доступности) = 21.
• Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что это будет минимально допустимое значение, которое потребуется для правильного выполнения сценария.

отслеживать_временная_метка_подтверждения

wal_keep_segments

wal_sender_timeout