當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 是對應(yīng)慢查詢的日志，當設(shè)置的值大于0 后，則超過對應(yīng)設(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們羨慕的應(yīng)該就是下面的選項，你不會在任何一個數(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)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。