解決PostgreSQL日志信息占用磁盤過大的問題
當PostgreSQL啟用日志時,若postgresql.conf日志的相關(guān)參數(shù)還使用默認值的話磁盤很容易被撐爆.因此在啟用了logging_collector參數(shù)時,需要對其它相關(guān)的參數(shù)進行調(diào)整.
系統(tǒng)默認參數(shù)如下
#log_destination = 'stderr' #日志格式,值為stderr, csvlog, syslog, and eventlog之一. logging_collector = on #啟用日志 #log_directory = 'log' #日志文件存儲目錄 #log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' #日志文件命名方,默認為每秒一個文件(postgresql-2017-10-18_231548.log) #log_file_mode = 0600 #日志文件權(quán)限 #log_truncate_on_rotation = off #是否截斷日志文件
調(diào)整后的參數(shù)
log_destination = 'csvlog' #日志格式,值為stderr, csvlog, syslog, and eventlog之一. logging_collector = on #啟用日志 log_directory = 'log' #日志文件存儲目錄 log_filename = 'postgresql-%j.log' #日志文件命名方式,最多保存一年的日志.同時要打開log_truncate_on_rotation,否則日志以追加的方式顯示在后面. log_file_mode = 0600 #日志文件權(quán)限 log_truncate_on_rotation = on #是否截斷日志文件
重點內(nèi)容
log_destination = 'csvlog' log_filename = 'postgresql-%j.log' log_truncate_on_rotation = on
log_destination:建議設(shè)置為csvlog,以便將日志鏈接到PostgreSQL中查看.參看Error Reporting and Logging 19.8.4. Using CSV-Format Log Output
log_filename :設(shè)置日志文件名,需結(jié)合log_truncate_on_rotation = on使用.可根據(jù)自己的需要調(diào)整, 例如:
log_filename = 'postgresql-%I.log' #最多保存12小時的日志,每小時一個文件 log_filename = 'postgresql-%H.log' #最多保存24小時的日志,每小時一個文件 log_filename = 'postgresql-%w.log' #最多保存一周的日志,每天一個文件 log_filename = 'postgresql-%d.log' #最多保存一個月的日志,每天一個文件 log_filename = 'postgresql-%j.log' #最多保存一年的日志,每天一個文件
補充：PostgreSQL 日志系統(tǒng) 及 設(shè)置錯誤導致磁盤塞滿案例
今天早上偶然看到QQ 群里面有一個人,在問問題,問題不重要,主要是沒有人回答, 然后這個人馬上就用非常讓人難以接受的詞匯,問候了群里面沒有回答他的一干人等, 其實我有點可憐他, 問一個問題沒有人回答,就如此,你是經(jīng)歷了什么,讓你連5分鐘的耐心都沒有, 每個人都有自己的生活軌跡, 不回答你是很正常的,
終究 nothing is impossible , right?
正文
在眾多的數(shù)據(jù)庫中，POSTGRESQL 的日志的系統(tǒng)的豐富度和日志的詳細的程度，都是可圈可點的，在網(wǎng)上不少同學都在問各種POSTGRESQL的問題，其實這些問題都可以在日志中找到答案，或者提交一些日志給問題的解決者，提高問題的解決速度和問題的定位的準確度。
首先我們先從日志的詳細度來入手，log_min_messages 定義了日志的詳細程度，其實我們在選擇上可能會有一些糾結(jié)，糾結(jié)點在error warning notice 這三種，大部分人可能在選擇error ，出錯就報錯誤，warning 也有相關(guān)選擇，實際上選擇不同的日志的詳細度也是有相關(guān)的一些考慮
1 如果你對PG本身不熟悉，測試系統(tǒng)可以開啟notice ，這樣便于你去查看一些你不理解，的東西并快速的進行學習，如果是生產(chǎn)系統(tǒng)初始階段可以開啟warning 對系統(tǒng)的初始時期的一些問題，可能是配置上，或者系統(tǒng)級別的一些問題進行更深的理解，如果是穩(wěn)定運行一段時間的系統(tǒng)則可以將其調(diào)整到 error 方面，降低一些不必要的日志的寫入，對性能和空間都有幫助。
這里建議大家可以使用warning 來作為常規(guī)的日志的詳細度的使用。
2 如果有人問，在語句執(zhí)行的時候，我的語句被莫名其名的kill 了我怎么查出來。下面的 log_min_error_statment 設(shè)置的選擇項就與其有關(guān)了，
例如下面的錯誤
ERROR: current transaction is aborted, commands ignored until end of transaction block STATEMENT: SELECT * FROM mytable WHERE id = 1 FOR UPDATE;
log_min_duration_statement 是對應慢查詢的日志，當設(shè)置的值大于0 后，則超過對應設(shè)置數(shù)字秒數(shù)的SQL 語句將被記錄。
這里需要考慮你的系統(tǒng)是OLAP OR OLTP 的情況，如果設(shè)置為 1秒，但你的系統(tǒng)里面的SQL 語句經(jīng)常要大于1秒，則你的日志中將大量充斥這樣的SQL 導致你的日志變得非常大。
說到這個MYSQL的DB會覺得PG的日志太亂了，MYSQL的日志大部分是分開的，這樣有利于日志的查看和分析。這里其實也建議PG是否可以考慮將日志分開，至少分為 SLOW LOG ERROR LOG SYSTEM LOG 等等。
當然說完不足，害的說優(yōu)點，讓其他數(shù)據(jù)庫DB們羨慕的應該就是下面的選項，你不會在任何一個數(shù)據(jù)庫中，找到如此豐富選擇配置
1 log_checkpoint 對當前的checkpoint的操作進行記錄，通過這個信息可以有兩點
1 有相關(guān)的監(jiān)控系統(tǒng)可以讀這些信息，生成圖標，讓這些信息成為一個趨勢圖來對系統(tǒng)進行分析，并修正系統(tǒng)
2 也可以手工寫python程序來收集信息，直接出報告或診斷
2 log_connections 用戶的登陸信息
3 log_disconnections 用戶的斷開的登陸的信息
4 log_error_verbosity 記錄信息的詳細程度，默認default
5 log_hostname 默認記錄信息中帶有客戶端的IP地址，不帶有對方的機器名
6 log_line_prefix 相當于對日志的打印的格式和信息的設(shè)置，有些監(jiān)控系統(tǒng)對此是有要求的，請按照你安裝的監(jiān)控系統(tǒng)的要求配置此欄
7 log_lock_waits 記錄語句執(zhí)行中的鎖等待時間
8 log_statement 對于什么語句進行記錄，（這個與上面的無關(guān)，有語句審計的時候可能需要打開這個開關(guān)，進行語句的收集，不建議使用all 否則對于系統(tǒng)的負擔太重，相當于在MYSQL中開啟genernal log）
實際上很多人在操作POSTGERSQL開始的時候，是找不到日志的，因為默認PG的日志默認是不打開的，關(guān)鍵的參數(shù)在 logging_collector 默認是off,所以安裝PG后的啟動前的第一件事情就是要將這個設(shè)置變?yōu)镺N ，好讓PG從開始就開始記錄日志。
另外日志的定期清理方面PG比其他的開源數(shù)據(jù)庫要做到好多了，因為不少人都的自己寫日志的rotate 和 clean up的腳本，PG 這里不需要，你只需要在 log_rotation_age中設(shè)置你要保留幾天的日志，同時 log_truncate_on_rotation 設(shè)置為on 就可以了，這點是非常人性化的。或者你也可以根據(jù)日志的大小進行設(shè)置如何拋棄他。
說完這些，我們來看看實際當中會遇到什么問題，以一個案例
在搭建完P(guān)G后，系統(tǒng)上線前并無問題，在系統(tǒng)上線后第二天，有人反饋PG的日志將系統(tǒng)的磁盤空間大量的占用，并且7 分鐘就產(chǎn)生一個日志文件，后續(xù)為了減少相關(guān)的日志的數(shù)量較快的增長，做了如下修改
log_rotation_size = 100MB
將日志的容量以及重置設(shè)置的更大
修改完畢后，不重新系統(tǒng)，直接加載后，日志的增長頻率已經(jīng)更改了。但日志的對磁盤空間的占用的問題還是沒有解決。
打開日志，系統(tǒng)記錄了大量如下的信息
罪魁禍首就是下面圖中的log_statement_stats 這個設(shè)置，將他打開后，系統(tǒng)會根據(jù)每個SQL 產(chǎn)生一個語句的性能方面的統(tǒng)計信息，可以想象如果將他打開可以看到每條語句在執(zhí)行中的狀態(tài)， duration 等等信息，但這樣就會產(chǎn)生大量的日志，經(jīng)過統(tǒng)計次系統(tǒng)1秒產(chǎn)生1MB的日志，（此系統(tǒng)每秒插入上百條數(shù)據(jù)），在關(guān)閉后，問題解決。
所以看似一個日志的設(shè)置，如果不熟悉系統(tǒng)，也會造成類似的問題，并且在緊急的狀態(tài)下，可能會用較長的時間來解決。實際上日志系統(tǒng)還有一些其他的細節(jié)，例如時區(qū)的問題，找機會可以在說說吧
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。
相關(guān)文章
啟動PostgreSQL服務(wù)器 并用pgAdmin連接操作
這篇文章主要介紹了啟動PostgreSQL服務(wù)器 并用pgAdmin連接操作，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01
使用PostgreSQL的JSONB數(shù)據(jù)類型進行高效查詢的示例代碼
PostgreSQL的JSONB數(shù)據(jù)類型提供了一種靈活的方式來存儲和查詢JSON格式的數(shù)據(jù),下面我們將詳細討論如何使用JSONB數(shù)據(jù)類型進行高效查詢,并提供相應的解決方案和示例代碼,需要的朋友可以參考下2024-04-04
在pg里表分區(qū)是通過表繼承來實現(xiàn)的，一般都是建立一個主表，里面是空，然后每個分區(qū)都去繼承它。2009-09-09
這篇文章主要介紹了PostgreSQL 修改視圖的操作，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01
這篇文章主要介紹了關(guān)于PostgreSQL 行排序的實例解析，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01
pg中的長事務(wù)會影響表中垃圾回收，導致表的年齡增長無法freeze。能消耗事務(wù)的只有當執(zhí)行了一些DML或者DDL操作后才能算是我們通常說的長事務(wù)。否則只能算是我們常說的長連接，當然長連接也有很多弊端，例如占用內(nèi)存、cpu等資源2022-09-09
這篇文章主要給大家介紹了關(guān)于PostgreSQL如何查看事務(wù)所占有鎖的相關(guān)資料,文中通過代碼以及圖文介紹的非常詳細,對大家學習或者使用PostgreSQL具有一定的參考借鑒價值,需要的朋友可以參考下2023-10-10
這篇文章主要介紹了PostgreSQL中關(guān)閉死鎖進程的方法,本文給出兩種解決這問題的方法,需要的朋友可以參考下2015-02-02
詳解PostgreSQL?14.4安裝使用及一些安裝的異常問題
這篇文章主要介紹了PostgreSQL?14.4的安裝以及使用以及一些安裝的異常,本文通過圖文并茂的形式給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-07-07
PostgreSQL 查找當前數(shù)據(jù)庫的所有表操作
這篇文章主要介紹了PostgreSQL 查找當前數(shù)據(jù)庫的所有表操作，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2020-12-12