PostgreSQL 9.5 數據庫在日誌中顯示損壞跡象，但客戶端正常工作
我們有一個在 Ubuntu 16.04 LTS 機器上執行 PostgreSQL 9.5 的數據庫伺服器，總數據大小略低於 30 GB。
我們已設置
archive_mode為on，並且archive_command正在將 WAL 文件同步到另一台執行 Barman 的伺服器。為了準備使用 的最終 PostgreSQL 升級pg_upgrade，我們設置了一個一次性伺服器實例，該實例也執行 PostgreSQL 9.5，我們將其用作barman recover. 我們的想法是獲取我們可以測試的數據庫快照到pg_upgrade在同一伺服器上執行的 PostgreSQL 12 實例。正是在這個過程中，
barman recover對一次性伺服器進行操作時，我發現了一個問題。目標數據庫已停止，在 Barman 完成對那里數據目錄內容的 rsync 之後，我重新啟動了伺服器。它正常上線並像往常一樣接受查詢，但此錯誤開始出現在日誌文件中：2020-12-08 12:05:20 EET ERROR: could not access status of transaction 79509466 2020-12-08 12:05:20 EET DETAIL: Could not open file "pg_clog/004B": No such file or directory. 2020-12-08 12:05:20 EET CONTEXT: automatic vacuum of table "template0.pg_catalog.pg_statistic"它在伺服器啟動時列印了四次，然後每 60 秒列印一次。
我最初認為這是 Barman 或其伺服器上的數據的問題，但由於在那裡找不到任何操作問題，我將目光轉向了生產伺服器本身。瞧，自 10 月 21 日以來，該錯誤已出現在生產伺服器上。因此，這絕不是備份或恢復過程出了什麼問題，而是實際的生產數據出了問題！
這已經被忽視了。10 月 21 日，伺服器（Upcloud 上的 VPS）上沒有發生任何事情，我們可以看出：我們所有的 Web 應用程序——我們都有強大的錯誤警報——依賴於伺服器一直保持正常工作。沒有人記得那天在那裡進行了任何手動操作。這可能是 VPS 提供商的問題，該提供商在 10 月 28 日報告檢測到儲存後端問題，之後很快得到解決。這是我們的問題首次出現在日誌中一周後，但我想症狀可能更早開始。
按字母順序，裡面的第一個文件
pg_clog是004C. 根據一些Google搜尋的建議，我嘗試創建一個全零的 256k 文件，名為004B. 在我這樣做之後，錯誤變為：2020-12-08 13:35:25 EET CONTEXT: automatic vacuum of table "template0.pg_catalog.pg_statistic" 2020-12-08 13:35:40 EET ERROR: found xmax 79509466 from before relfrozenxid 80163082（這是在作為
barman recover目標的一次性伺服器上，我不敢接觸生產。）每隔 15 秒列印一次。我不知道如何進一步分析，更不用說解決這個問題了。就我們的數據庫客戶端而言，一切正常，但這需要糾正。任何幫助表示讚賞。請注意，我對 PostgreSQL 數據儲存內部結構的了解接近於零。
如果只是
pg_statistic受到影響，您可能會擺脫這種便宜：設置
allow_system_table_mods = on並postgresql.conf重新啟動 PostgreSQL。然後執行TRUNCATE pg_catalog.pg_statistic; ANALYZE;完成後不要忘記重置
allow_system_table_mods。但是你永遠不應該相信數據庫損壞的 PostgreSQL 數據庫集群。創建一個新集群，導出舊集群
pg_dumpall並將其導入新集群。然後丟棄數據損壞的集群。您可能希望創建新集群，
--data-checksums以便在磁碟上的數據更改時收到錯誤消息。現在您應該調查可能的原因。升級到最新的次要版本並測試您的硬體是否存在問題。
目標數據庫已停止，在 Barman 完成對那里數據目錄內容的 rsync 之後，我重新啟動了伺服器。
您在冷伺服器頂部從正在執行的伺服器中同步數據？這不是一種受支持的處理方式，除非執行的伺服器首先進入備份模式，然後冷伺服器進行恢復。你說酒保是為你做的，我想我沒有聽說過酒保被這樣使用。您能否提供用於此過程的所有酒保命令的完整命令行？