максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
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
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальный размер WAL, который может быть зарезервирован слотами репликации. |
| Тип данных |
целое число |
| Значение по умолчанию |
-1 |
| Допустимые значения |
-1 |
| Тип параметра |
только для чтения |
| Документация |
max_slot_wal_keep_size |
max_wal_senders
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отслеживать_время_коммита
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_size
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
400 |
| Допустимые значения |
400 |
| Тип параметра |
только для чтения |
| Документация |
wal_keep_size |
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
максимум слотов репликации |
Заметки, относящиеся к 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
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальный размер WAL, который может быть зарезервирован слотами репликации. |
| Тип данных |
целое число |
| Значение по умолчанию |
-1 |
| Допустимые значения |
-1 |
| Тип параметра |
только для чтения |
| Документация |
максимальный размер хранения WAL-слота |
max_wal_senders
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
максимальное количество отправителей wal (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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
фиксировать_временную_метку_фиксации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_size (Размер удержания WAL)
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
400 |
| Допустимые значения |
400 |
| Тип параметра |
только для чтения |
| Документация |
wal_keep_size |
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
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.
размер хранения WAL для slot_max
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальный размер WAL, который может быть зарезервирован слотами репликации. |
| Тип данных |
целое число |
| Значение по умолчанию |
-1 |
| Допустимые значения |
-1 |
| Тип параметра |
только для чтения |
| Документация |
max_slot_wal_keep_size |
max_wal_senders
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отслеживать_время_коммита
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_size
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
400 |
| Допустимые значения |
400 |
| Тип параметра |
только для чтения |
| Документация |
wal_keep_size |
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
макс_слотов_репликации |
Заметки, относящиеся к 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
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальный размер WAL, который может быть зарезервирован слотами репликации. |
| Тип данных |
целое число |
| Значение по умолчанию |
-1 |
| Допустимые значения |
-1 |
| Тип параметра |
только для чтения |
| Документация |
max_slot_wal_keep_size |
max_wal_senders
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отслеживание_времени_фиксации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_size
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
400 |
| Допустимые значения |
400 |
| Тип параметра |
только для чтения |
| Документация |
wal_keep_size |
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
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.
Размер_хранения_слот_вал_макс
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальный размер WAL, который может быть зарезервирован слотами репликации. |
| Тип данных |
целое число |
| Значение по умолчанию |
-1 |
| Допустимые значения |
-1 |
| Тип параметра |
только для чтения |
| Документация |
max_slot_wal_keep_size |
max_wal_senders
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отметка времени фиксации изменений
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_size
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает размер ФАЙЛОВ WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
400 |
| Допустимые значения |
400 |
| Тип параметра |
только для чтения |
| Документация |
wal_keep_size |
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
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
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отметка времени фиксации изменений
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_segments
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает количество файлов WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
25 |
| Допустимые значения |
25 |
| Тип параметра |
только для чтения |
| Документация |
|
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |
максимальное_количество_слотов_репликации
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Указывает максимальное количество слотов репликации, которые может поддерживать сервер. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
2-262143 |
| Тип параметра |
статичный |
| Документация |
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
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное число одновременно выполняющихся процессов отправителя WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
10 |
| Допустимые значения |
5-100 |
| Тип параметра |
статичный |
| Документация |
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, назначенным для выполнения логической репликации, все просыпаются:
- Декодирование всех новых записей в WAL,
- Отфильтровать записи журнала, которые они не заинтересованы,
- Реплицируйте данные, относящиеся к каждому из них.
- Отправители 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.
- Если вы по-прежнему считаете, что максимально допустимое значение для этого параметра слишком низко для ваших потребностей, обратитесь к нам, подробно опишите свой сценарий и объясните, что вы считаете, что будет минимальным допустимым значением, которое потребуется для правильного выполнения сценария.
отметка времени фиксации изменений
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Собирает время фиксации транзакции. |
| Тип данных |
булевый |
| Значение по умолчанию |
off |
| Допустимые значения |
on,off |
| Тип параметра |
статичный |
| Документация |
track_commit_timestamp |
wal_keep_segments
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает количество файлов WAL, удерживаемых для резервных серверов. |
| Тип данных |
целое число |
| Значение по умолчанию |
25 |
| Допустимые значения |
25 |
| Тип параметра |
только для чтения |
| Документация |
|
wal_sender_timeout
| Атрибут |
Значение |
| Категория |
Репликация и отправка серверов |
| Описание |
Задает максимальное время ожидания репликации WAL. |
| Тип данных |
целое число |
| Значение по умолчанию |
60000 |
| Допустимые значения |
0-2147483647 |
| Тип параметра |
динамический |
| Документация |
wal_sender_timeout |