Хочу сделать хот-стендбай, что сделал: postgresql_master.conf: max_connections = 40

# (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
shared_buffers = 7680MB # min 128kB
work_mem = 49MB # min 64kB
maintenance_work_mem = 1920MB # min 1MB
dynamic_shared_memory_type = posix # the default is usually the first option
effective_io_concurrency = 200 # 1-1000; 0 disables prefetching
max_worker_processes = 20 # (change requires restart)
max_parallel_workers_per_gather = 4 # taken from max_parallel_workers
max_parallel_maintenance_workers = 4 # taken from max_parallel_workers
max_parallel_workers = 20 # maximum number of max_worker_processes that
max_wal_size = 4GB
min_wal_size = 1GB
hot_standby_feedback = on # send info from standby to prevent
random_page_cost = 1.1 # same scale as above
effective_cache_size = 23040MB
log_min_duration_statement = 1000 # -1 is disabled, 0 logs all statements
log_statement_sample_rate = 0.2 # fraction of logged statements exceeding
cluster_name = '15/main' # added to process titles if nonempty
datestyle = 'iso, mdy'
timezone = 'UTC'
shared_preload_libraries = 'pg_stat_statements,auto_explain' # (change requires restart)
auto_explain.log_min_duration = 2000
auto_explain.log_analyze = on
auto_explain.log_triggers = on
auto_explain.log_nested_statements = on
include_dir = 'conf.d' # include files ending in '.conf' from
slave.conf:
max_connections = 40 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
shared_buffers = 7680MB # min 128kB
work_mem = 49MB # min 64kB
maintenance_work_mem = 1920MB # min 1MB
dynamic_shared_memory_type = posix # the default is usually the first option
effective_io_concurrency = 200 # 1-1000; 0 disables prefetching
max_worker_processes = 20 # (change requires restart)
max_parallel_workers_per_gather = 4 # taken from max_parallel_workers
max_parallel_maintenance_workers = 4 # taken from max_parallel_workers
max_parallel_workers = 20 # maximum number of max_worker_processes that
wal_log_hints = on # also do full page writes of non-critical updates
max_wal_size = 4GB
min_wal_size = 1GB
hot_standby_feedback = on # send info from standby to prevent
random_page_cost = 1.1 # same scale as above
effective_cache_size = 23040MB
log_min_duration_statement = 1000 # -1 is disabled, 0 logs all statements
log_statement_sample_rate = 0.2 # fraction of logged statements exceeding
log_line_prefix = '%m [%p] %q%u@%d ' # special values:
log_timezone = 'UTC'
cluster_name = '15/main' # added to process titles if nonempty
datestyle = 'iso, mdy'
timezone = 'UTC'
auto_explain.log_min_duration = 2000
auto_explain.log_analyze = on
auto_explain.log_triggers = on
auto_explain.log_nested_statements = on
include_dir = 'conf.d'
создал реплику так:
pg_basebackup -P -R -X stream -c fast -h host -U replica_user -D ./main
оно работает,
как я понял, чтобы промоутнуть реплику до мастера я могу добавить в настройках ссылку на файл, который, если появляется, прмоутит слейв.
но что-то я туплю с демоутом. что происходит тогда, когда мастер снова активен, достаточно ли убрать файл или нужны какие-то ещё действия.
хотелось бы избежать сплит-брейна, может я ещё что-то упускаю?
+вопрос по роутингу р/о запросов на слейв, какие есть подводные камни, что можете посоветовать?

может воспользоваться уже существующими наработками на тему? например патрони

>достаточно ли убрать файл или нужны какие-то ещё действия. Да, нужно остановить его, синхонизировать с новым ведущим (например, можэт помочь pg_rewind. Ну, или rsync, или pg_basebackup...) и потом можно создавать standby.signal и запускать его заново в режыме веомого.

И б-жэ вас упаси от патрони...

>+вопрос по роутингу р/о запросов на слейв, какие есть подводные камни, что можете посоветовать? Все варианты, кроме как непосредственно в клиенте определять -- нужэн ведущий или нет -- являются какой-то противоестественной эклектикой. Нет, не то, чтобы они совсем были никудышные -- можно разобраться, что имел в виду автор, и как к этому привести -- но непонятно, зачем. Если лучшэ всего это знает именно клиентское приложэние. (Адреса ведущего и ведомого получать из любого твоего конфиг стораджа.)

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

Илья, а чем плох Patroni? Хочется услышать один, два аргумента против него..

получается, делаю recovery.signal, и настраиваю recovery_command, правильно понимаю, что если чексуммы включены глобально, то нет нужды в wal_log_hints или я ошибаюсь? (pg_rewind requires that the target server either has the wal_log_hints option enabled in postgresql.conf or data checksums enabled )

Да, правильно понимашь

Там ещё full_page_writes включить надо

от pg_rewind откажитесь сразу )

https://t.me/PostgreSQL_1C_Linux/129202

Спасибо.

ну представим ситуацию, что у вас включен archive_mode. У вас мастер пишет walы, он вылетает, его роль берёт реплика. В патрони у вас сменится TL и walы также будут писаться. Потом приезжает упавший мастер и не успев понять, что он не мастер записал в архив свои walы, но так как сменился TL он не перезапишет правильные walы, что произошло бы если TL не сменился.

>, его роль берёт реплика. В этот момент у неё меняется TL, и никто никого не перезапишэт. Патрони жэ сменит TL у бывшэго ведущего, если он рестартнётся -- потому во-первых, шансы на перезапись правильной новой TL появляются. Во-вторых, шансы на pg_rewind -- исчезают.

почему он вдруг сменит TL у бывшего ведущего?

Ладно, в этом случае -- действительно не должэн. (Я просто привык, что патрони накручивает таймлайн при каждом рестарте сервера -- вот и неподумал, что тут у нас с точки зрения патрони не ведущий ужэ).