Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющем файле. Изменения значений этих параметров передаются через журнал (WAL) на реплики, где сохраняются в управляющем файле реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.
Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:
pg_controldata | grep max_
max_connections setting: 100
max_worker_processes setting: 8
max_wal_senders setting: 10
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64Эти параметры описаны в документации ( https://docs.tantorlabs.ru/tdb/ru/16_8/se1c/hot-standby.html ). Так как страница документации довольно большая, найти место, где перечислены пять параметров сложно. Помимо пяти перечисленных параметров, в управляющем файле сохраняются значения ещё трёх параметров конфигурации: wal_log_hints, track_commit_timestamp, wal_level:
pg_controldata | egrep "^wal|track"
wal_level setting: replica
wal_log_hints setting: off
track_commit_timestamp setting: offПри изменении любого из восьми параметров, формируется журнальная запись типа record_type=PARAMETER_CHANGE от менеджера ресурсов res=XLOG. В формируемой журнальной записи присутствуют значения всех восьми параметров. Пример запроса, которым можно найти в журнале менялся ли один из восьми отслеживаемых параметров:
postgres=# create extension pg_walinspect;
select resource_manager res, record_type, start_lsn, end_lsn, prev_lsn, record_length len, left(description,200) data from pg_get_wal_records_info((select '0/0'::pg_lsn + (pg_split_walfile_name(name(habr))).segment_number * size from pg_ls_waldir() habr order by name limit 1), 'FFFFFFFF/FFFFFFFF') "dba1.ru" where record_type like '%PARAMETER_CHANGE%' order by 3 limit 20\gx
-[ RECORD 1 ]-----------------------------------
res | XLOG
record_type | PARAMETER_CHANGE
start_lsn | 1/300000C0
end_lsn | 1/300000F8
prev_lsn | 1/30000028
len | 56
data | max_connections=100 max_worker_processes=8
max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=64
wal_level=replica wal_log_hints=off track_commit_timestamp=offПо умолчанию, в диагностический журнал изменения значений этих параметров не записываются, хотя это было бы полезно. Можно провести аналогию, что логирование контрольных точек включили только в версии PostgreSQL 15, хотя параметр log_checkpoints появился ещё в версии 8.3.
В диагностическом логе запись появится, только если процесс startup остановит свою работу:
[46120] WARNING: hot standby is not possible because of insufficient parameter settings
[46120] DETAIL: max_connections = 100 is a lower setting than on the primary server, where its value was 101.
[46120] CONTEXT: WAL redo at 1/30000400 for XLOG/PARAMETER_CHANGE: max_connections=101 max_worker_processes=8 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=64 wal_level=replica wal_log_hints=off track_commit_timestamp=off
Причины отслеживания параметров на репликах
1) Параметры max_connections, max_worker_processes, max_wal_senders отслеживаются по следующей причине.
При запуске процесса startup проверяется, что wal_level установлен в replica или logical. В xlog.c в описании функции CheckRequiredParameterValues(void) причина описана так: For Hot Standby, the WAL must be generated with 'replica' mode, and we must have at least as many backend slots as the primary. То есть, число структур памяти для хранения состояния процессов, на реплике должно быть не меньше, чем на мастере в режиме hot_standby=on.
Размер структур памяти, выделяемых под хранение состояния процессов экземпляра, определяется формулой:2 * (max_connections + autovacuum_max_workers + 1 + max_wal_senders + max_worker_processes). Почему в начале формулы двойка? Если вы знаете, то вы хороший разработчик ядра PostgreSQL. Важно то, что в формулу входят три из пяти параметров, значения которых которые должны быть установлены в значения, не меньшие, чем на мастере.
В формуле присутствует параметр autovacuum_max_workers, но он не отслеживается, так как на реплике в режиме восстановления процессы автовакуума не запускаются.
2) Параметры max_locks_per_transaction, max_prepared_transactions и ещё раз max_connections отслеживаются по следующей причине. Структуры общей памяти для отслеживания идентификаторов транзакций, блокировок и подготовленных транзакций на резервном сервере должны быть не меньше, чем на мастере, чтобы гарантировать, что реплика не исчерпает общую память во время наката журнала. Например, если на мастере выполнялась подготовленная транзакция, а на реплике память для отслеживания подготовленных транзакций не смогла выделиться, то накат журнальной записи не сможет выполниться. Чтобы такого не было, указанные структуры памяти реплики должны быть не меньше, чем на мастере.
Размер структуры памяти, которая выделяется под хранение блокировок ("таблица блокировок") определяется формулой: max_locks_per_transaction * (max_connections + max_prepared_transactions), куда и входят оставшиеся два параметра. Эта формула определяет гарантированное число блокировок, которые могут установить в сумме все (или один, например, startup) процессы экземпляра. Знали ли вы, что в формулу входит параметр max_prepared_transactions? Если знали, то вы хороший администратор PostgreSQL.
Мы выяснили причины, по которым пять параметров на реплике должны иметь значения, не меньше , чем на мастере. Дальше посмотрим что произойдёт при изменении значений параметров.
Реплика не обслуживает запросы (hot_standby=off)
Если hot_standby=off, то к реплике нельзя подсоединиться:
FATAL: the database system is not accepting connections
DETAIL: Hot standby mode is disabled.
Процесс startup применяет значения всех восьми параметров (и увеличение и уменьшение и изменение значений) путем внесения изменений в управляющий файл реплики и продолжает накат журнала. При этом изменения в конфигурационные файлы реплики (postgresql.auto.conf и postgresql.conf) процессом не вносятся.
Если в журнальной записи придет значение wal_level=minimal, то процесс startup реплики перестанет применять журнальные записи и реплику придется пересоздавать. Пример сообщений процесса startup перед его остановкой:
[46507] LOG: entering standby mode
[46507] FATAL: WAL was generated with "wal_level=minimal", cannot continue recovering
[46507] DETAIL: This happens if you temporarily set "wal_level=minimal" on the server.
[46507] HINT: Use a backup taken after setting "wal_level" to higher than "minimal".
[46503] LOG: startup process (PID46507) exited with exit code 1
Значение wal_level=minimal может быть установлено на мастере автоматически при изменении размера WAL-файлов. Размеры WAL-файлов могут меняться (по степеням двойки) утилитой pg_resetwal.
Значение wal_level=minimal не может быть установлено в параметрах реплики, при запуске экземпляра реплики возникнет ошибка:
FATAL: WAL streaming ("max_wal_senders" > 0) requires "wal_level" to be "replica" or "logical"
stopped waiting
В управляющем файле реплики процесс startup может сохранить значение wal_level=logical:
postgres@tantor:~$ pg_controldata -D /var/lib/postgresql/backup/1 | grep level
wal_level setting: logicalпри этом в параметрах конфигурации реплики может быть установлен wal_level=replica и процессами экземпляра реплики будет использоваться значение replica:
postgres@tantor:~$ psql -p 5433 -c "select name, setting, boot_val, reset_val, pending_restart from pg_settings where name='wal_level';"
name | setting | boot_val | reset_val | pending_restart
-----------+---------+----------+-----------+-----------------
wal_level | replica | replica | replica | f
(1 row)Если поменять значение параметра hot_standby с off на on, то в проверяются значения пяти параметров в управляющем файле реплики и, если их значения больше, чем у параметров конфигурации, с которыми был запущен экземпляр реплики, то экземпляр реплики останавливается и в диагностический лог записывается ошибка, связанная только с одним из параметров:
[73109] LOG: entering standby mode
[73109] FATAL: recovery aborted because of insufficient parameter settings
[73109] DETAIL: max_connections = 100 is a lower setting than on the primary server, where its value was 102.
[73109] HINT: You can restart the server after making the necessary configuration changes.
[73105] LOG: startup process (PID 73109) exited with exit code 1
[73105] LOG: aborting startup due to startup process failure
[73105] LOG: database system is shut down
Это происходит потому, что процесс startup меняет значения в управляющем файле реплики, но не вносит изменения в файлы параметров конфигурации. Утилита pg_basebackup при использовании параметра -R может напрямую вносить изменения в файл postgresql.auto.conf, а процесс startup не может. То есть теоретических предпосылок, почему бы процессу startup не быть "user friendly" и не вносить изменения в postgresql.auto.conf нет.
Если поменять значение параметра и снова попробовать запустить экземпляр, то выдастся ошибка на следующий параметр:
[73158] LOG: entering standby mode
[73158] FATAL: recovery aborted because of insufficient parameter settings
[73158] DETAIL: max_worker_processes = 8 is a lower setting than on the primary server, where its value was 9.
[73158] HINT: You can restart the server after making the necessary configuration changes.
[73154] LOG: startup process (PID 73158) exited with exit code 1
[73154] LOG: aborting startup due to startup process failure
[73154] LOG: database system is shut down
и так, пока значения всех пяти параметров не будут установлены в значение, не меньшее, чем в управляющем файле реплики, в который эти значения были внесены процессом startup.
Горячая реплика (hot_standby=on)
Режим горячей реплики включается параметром конфигурации hot_standby=on. Изменить значение этого параметра можно только перезапуском экземпляра реплики. Если hot_standby=on, то процесс startup, видя журнальную запись с новыми значениями восьми параметров, проверяет значения пяти параметров. Также проверяется, чтобы значение wal_level не было равно minimal. Изменение любого значения из этих параметров требует рестарт экземпляра. Если значения запущенного экземпляра реплики меньше, чем значение, полученное от мастера в журнальной записи по пяти параметрам, то процесс startup вносит изменения параметров в управляющий файл реплики и прекращает применение журнала. Без рестарта экземпляра реплики продолжить применение невозможно:
[46143] LOG: started streaming WAL from primary at 1/30000000 on timeline 1
[46120] WARNING: hot standby is not possible because of insufficient parameter settings
[46120] DETAIL: max_connections = 100 is a lower setting than on the primary server, where its value was 101.
[46120] CONTEXT: WAL redo at 1/30000400 for XLOG/PARAMETER_CHANGE: max_connections=101 max_worker_processes=8 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=64 wal_level=replica wal_log_hints=off track_commit_timestamp=off
[46120] LOG: recovery has paused
[46120] DETAIL: If recovery is unpaused, the server will shut down.
[46120] HINT: You can then restart the server after making the necessary configuration changes.
Чтобы продолжить нужно либо установить hot_standby=off и рестартовать экземпляр реплики, но это не имеет смысла, так как при установке hot_standby=on будет ошибка запуска экземпляра. Значит нужно менять значения параметров конфигурации. Командой ALTER SYSTEM это можно сделать, если не остановить экземпляр реплики. Если экземпляр остановить, то экземпляр не запустится, о чем процесс startup предупредил в приведенном выше диагностическом сообщении "DETAIL: If recovery is unpaused, the server will shut down". Пример, что будет при рестарте экземпляра реплики, если значения в управляющем файле реплики больше, чем значения на экземпляре (берутся из конфигурационных файлов):
[75813] LOG: entering standby mode
[75813] FATAL: recovery aborted because of insufficient parameter settings
[75813] DETAIL: max_connections = 102 is a lower setting than on the primary server, where its value was 103.
[75813] HINT: You can restart the server after making the necessary configuration changes.
[75809] LOG: startup process (PID 75813) exited with exit code 1
[75809] LOG: aborting startup due to startup process failure
[75809] LOG: database system is shut down
Пример содержимого управляющего файла при возникновении этой ошибки:
postgres@tantor:~$ pg_controldata -D /var/lib/postgresql/backup/1 | grep max_conn
max_connections setting: 103Вывод
Перед изменением любого из пяти параметров:
max_connections (в управляющем файле называется
max_worker_processes
max_wal_senders
max_prepared_transactionsmax_prepared_xacts)
max_locks_per_transaction (в управляющем файле называется max_locks_per_xact)
стоит проверить значения этих параметров в файлах параметров всех реплик и установить на репликах значения так, чтобы значения были не меньше, чем на мастере (или планируются к установке на мастере). В противном случае, реплика перестанет накатывать журнальные записи до тех пор, пока не будут изменены значения параметров, после чего экземпляр реплики должен быть перезапущен, так как изменение значения любого из пяти параметров требует рестарт экземпляра.
Устанавливать для wal_level значение minimal не стоит ни на мастере, ни на репликах. Если установить значение minimal на мастере, то это повлияет на реплику так, что она не сможет применять журнал пока не будет пересоздана: Use a backup taken after setting "wal_level" to higher than "minimal".
