安全關閉看似配置錯誤（但工作正常）的 PostgreSQL 複製/歸檔

我正在幫助管理兩台 PostgreSQL 伺服器（一台主伺服器，一台副本伺服器）以及一台執行 Barman 以進行 WAL 歸檔的單獨伺服器。我最初並沒有參與設置複製和歸檔。配置相當陳舊，其中一些可以追溯到 2015 年和 PostgreSQL 9.3，儘管我們現在執行的是 9.5。遺憾的是，配置更改的歷史沒有記錄。建構設置的人還在，但這也是他們第一次設置複製。

前段時間，在我們的 VPS 提供商出現一些儲存系統故障後，我們在主伺服器上遇到了一個神秘的數據損壞問題。即使將 Barman 備份還原到新伺服器時，這些問題也存在。這阻止了我們乾淨地升級到 PostgreSQL 12，但我們確定我們能夠乾淨地轉儲main集群中的實際生產數據庫並將其恢復到新創建的恢復集群。

我們決定關閉我們的複制 + Barman 歸檔設置並從頭開始它們，在研究如何做到這一點時，我遇到了一些有趣的配置問題。tl; dr：目前設置正在執行，但不是我想像的那樣，現在我需要有關如何徹底關閉它的指導。

出現問題的第一個線索是當我查看在主伺服器上配置了哪些複製槽時，使用select * from pg_replication_slots. 令我困惑的是，這沒有產生任何結果。我的假設（基於建構設置的人的描述）是我們至少為 Barman 使用插槽，我認為我們也會為複制使用插槽。

在我進一步討論之前，這裡是來自三台伺服器的相關設置，其中敏感細節已更改：

# Primary server's postgresql.conf
wal_level = hot_standby
max_wal_senders = 4

archive_mode = on
archive_command = 'rsync -a %p companyuser@backup-server:/backup/thingamabob/incoming/%f'
max_replication_slots = 2

# Replica server's postgresql.conf
wal_level = hot_standby
hot_standby = on

# Replica server's recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=primary-server user=postgres'
trigger_file = '/tmp/trigger_file0'

# /home/companyuser/.barman.conf on the backup server
[barman]
barman_home = /backup
barman_user = companyuser
log_file = /backup/barman.log
minimum_redundancy = 1

[thingamabob]
description = "Thingamabob"
archiver = on
# 5436 is the SSH tunneled port to our primary DB server, which has
# a 'barman' user
conninfo = host=localhost port=5436 user=barman dbname=postgres
backup_method = postgres
slot_name = backup
retention_policy = RECOVERY WINDOW OF 4 DAYS
retention_policy_mode = auto

讓我們先看看 Barman WAL 歸檔方面，我想我已經弄清楚了。archive_mode並且archive_command正在rsync從主伺服器到備用伺服器的完整 WAL 段，並且 Barman 具有到主伺服器的必要控制連接。顯然由於誤解，設置了.barman.conf，slot_name = backup即使我們只使用傳統的 WAL 歸檔，並且slot_name被 Barman 更新的 WAL 流功能使用。這裡的致命贈品是缺少streaming_archiverandstreaming_conninfo設置。因此，該設置是無用的，但幸運的是在此設置中是無害的。

我不太明白的是複制設置。我們在這裡沒有使用插槽（recovery.conf沒有primary_slot_name設置），並且設置的文件standby_mode沒有primary_conninfo告訴我複制實際上是如何正常執行的。

最後，根據目前提供的資訊提出一些具體問題：

1. 我們沒有使用複制槽，也沒有wal_keep_segments，也沒有restore_command。我的假設是，我們的複制設置完全靠運氣：副本伺服器沒有出現明顯的停機時間，因此無論主伺服器的預設 WAL 文件保留期是什麼，都足以讓我們的複制永遠不會因主伺服器而失敗刪除副本尚未收到的舊 WAL 文件。這個假設正確嗎？
2. 副本伺服器如何知道何時以及從何處從主伺服器檢索 WAL 文件？我們的設置實際上是在做什麼，或者 PostgreSQL 預設只是實現了這一點？它是在投票primary_conninfo嗎？
3. 我假設結束 Barman WAL 歸檔的簡單方法是從主伺服器的配置中刪除archive_mode和archive_command設置，然後停止barman cron在備份伺服器上每分鐘執行一次。它是否正確？根據我對文件的閱讀，archive_mode不涉及複製方面的事情。
4. 終止複制的正確方法是什麼？我目前的假設是做以下兩件事之一，但其中任何一件實際上是正確的嗎？

• 關閉副本伺服器上的 Postgres，刪除standby_mode設置，刪除recovery.conf，然後再次啟動 Postgres，它將像主伺服器一樣工作。
• 創建觸發器文件並等待恢復完成，然後可能刪除standby_mode並重新啟動 Postgres..？我不太確定standby_mode恢復結束後的行為。

1. 是的。
2. 備用伺服器定期執行還原點，即備用模式下的檢查點。啟動時，它會檢查其控製文件以查找最新的還原點並從那裡恢復。在它完成重放本地 WAL 後，它會連接到主節點並從該點開始請求 WAL。
3. 是的。
4. 以您喜歡的任何順序關閉兩台伺服器。如果要確保副本已趕上，請先關閉主伺服器。

引用自：https://dba.stackexchange.com/questions/283084