當(dāng)PostgreSQL啟用日志時(shí),若postgresql.conf日志的相關(guān)參數(shù)還使用默認(rèn)值的話磁盤(pán)很容易被撐爆.因此在啟用了logging_collector參數(shù)時(shí),需要對(duì)其它相關(guān)的參數(shù)進(jìn)行調(diào)整.

系統(tǒng)默認(rèn)參數(shù)如下

#log_destination = 'stderr' #日志格式,值為stderr, csvlog, syslog, and eventlog之一.
logging_collector = on #啟用日志
#log_directory = 'log' #日志文件存儲(chǔ)目錄
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' #日志文件命名方,默認(rèn)為每秒一個(gè)文件(postgresql-2017-10-18_231548.log)
#log_file_mode = 0600 #日志文件權(quán)限
#log_truncate_on_rotation = off #是否截?cái)嗳罩疚募?/pre>

調(diào)整后的參數(shù)

log_destination = 'csvlog' #日志格式,值為stderr, csvlog, syslog, and eventlog之一.
logging_collector = on #啟用日志
log_directory = 'log' #日志文件存儲(chǔ)目錄
log_filename = 'postgresql-%j.log' #日志文件命名方式,最多保存一年的日志.同時(shí)要打開(kāi)log_truncate_on_rotation,否則日志以追加的方式顯示在后面.
log_file_mode = 0600 #日志文件權(quán)限
log_truncate_on_rotation = on #是否截?cái)嗳罩疚募?/pre>

重點(diǎn)內(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小時(shí)的日志,每小時(shí)一個(gè)文件
log_filename = 'postgresql-%H.log' #最多保存24小時(shí)的日志,每小時(shí)一個(gè)文件
log_filename = 'postgresql-%w.log' #最多保存一周的日志,每天一個(gè)文件
log_filename = 'postgresql-%d.log' #最多保存一個(gè)月的日志,每天一個(gè)文件
log_filename = 'postgresql-%j.log' #最多保存一年的日志,每天一個(gè)文件

補(bǔ)充：PostgreSQL 日志系統(tǒng) 及 設(shè)置錯(cuò)誤導(dǎo)致磁盤(pán)塞滿案例

今天早上偶然看到QQ 群里面有一個(gè)人,在問(wèn)問(wèn)題,問(wèn)題不重要,主要是沒(méi)有人回答, 然后這個(gè)人馬上就用非常讓人難以接受的詞匯,問(wèn)候了群里面沒(méi)有回答他的一干人等, 其實(shí)我有點(diǎn)可憐他, 問(wèn)一個(gè)問(wèn)題沒(méi)有人回答,就如此,你是經(jīng)歷了什么,讓你連5分鐘的耐心都沒(méi)有, 每個(gè)人都有自己的生活軌跡, 不回答你是很正常的,

終究 nothing is impossible , right?

正文

在眾多的數(shù)據(jù)庫(kù)中，POSTGRESQL 的日志的系統(tǒng)的豐富度和日志的詳細(xì)的程度，都是可圈可點(diǎn)的，在網(wǎng)上不少同學(xué)都在問(wèn)各種POSTGRESQL的問(wèn)題，其實(shí)這些問(wèn)題都可以在日志中找到答案，或者提交一些日志給問(wèn)題的解決者，提高問(wèn)題的解決速度和問(wèn)題的定位的準(zhǔn)確度。

首先我們先從日志的詳細(xì)度來(lái)入手，log_min_messages 定義了日志的詳細(xì)程度，其實(shí)我們?cè)谶x擇上可能會(huì)有一些糾結(jié)，糾結(jié)點(diǎn)在error warning notice 這三種，大部分人可能在選擇error ，出錯(cuò)就報(bào)錯(cuò)誤，warning 也有相關(guān)選擇，實(shí)際上選擇不同的日志的詳細(xì)度也是有相關(guān)的一些考慮

1 如果你對(duì)PG本身不熟悉，測(cè)試系統(tǒng)可以開(kāi)啟notice ，這樣便于你去查看一些你不理解，的東西并快速的進(jìn)行學(xué)習(xí)，如果是生產(chǎn)系統(tǒng)初始階段可以開(kāi)啟warning 對(duì)系統(tǒng)的初始時(shí)期的一些問(wèn)題，可能是配置上，或者系統(tǒng)級(jí)別的一些問(wèn)題進(jìn)行更深的理解，如果是穩(wěn)定運(yùn)行一段時(shí)間的系統(tǒng)則可以將其調(diào)整到 error 方面，降低一些不必要的日志的寫(xiě)入，對(duì)性能和空間都有幫助。

這里建議大家可以使用warning 來(lái)作為常規(guī)的日志的詳細(xì)度的使用。

2 如果有人問(wèn)，在語(yǔ)句執(zhí)行的時(shí)候，我的語(yǔ)句被莫名其名的kill 了我怎么查出來(lái)。下面的 log_min_error_statment 設(shè)置的選擇項(xiàng)就與其有關(guān)了，

例如下面的錯(cuò)誤

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 是對(duì)應(yīng)慢查詢的日志，當(dāng)設(shè)置的值大于0 后，則超過(guò)對(duì)應(yīng)設(shè)置數(shù)字秒數(shù)的SQL 語(yǔ)句將被記錄。

這里需要考慮你的系統(tǒng)是OLAP OR OLTP 的情況，如果設(shè)置為 1秒，但你的系統(tǒng)里面的SQL 語(yǔ)句經(jīng)常要大于1秒，則你的日志中將大量充斥這樣的SQL 導(dǎo)致你的日志變得非常大。

說(shuō)到這個(gè)MYSQL的DB會(huì)覺(jué)得PG的日志太亂了，MYSQL的日志大部分是分開(kāi)的，這樣有利于日志的查看和分析。這里其實(shí)也建議PG是否可以考慮將日志分開(kāi)，至少分為 SLOW LOG ERROR LOG SYSTEM LOG 等等。

當(dāng)然說(shuō)完不足，害的說(shuō)優(yōu)點(diǎn)，讓其他數(shù)據(jù)庫(kù)DB們羨慕的應(yīng)該就是下面的選項(xiàng)，你不會(huì)在任何一個(gè)數(shù)據(jù)庫(kù)中，找到如此豐富選擇配置

1 log_checkpoint 對(duì)當(dāng)前的checkpoint的操作進(jìn)行記錄，通過(guò)這個(gè)信息可以有兩點(diǎn)

1 有相關(guān)的監(jiān)控系統(tǒng)可以讀這些信息，生成圖標(biāo)，讓這些信息成為一個(gè)趨勢(shì)圖來(lái)對(duì)系統(tǒng)進(jìn)行分析，并修正系統(tǒng)

2 也可以手工寫(xiě)python程序來(lái)收集信息，直接出報(bào)告或診斷

2 log_connections 用戶的登陸信息

3 log_disconnections 用戶的斷開(kāi)的登陸的信息

4 log_error_verbosity 記錄信息的詳細(xì)程度，默認(rèn)default

5 log_hostname 默認(rèn)記錄信息中帶有客戶端的IP地址，不帶有對(duì)方的機(jī)器名

6 log_line_prefix 相當(dāng)于對(duì)日志的打印的格式和信息的設(shè)置，有些監(jiān)控系統(tǒng)對(duì)此是有要求的，請(qǐng)按照你安裝的監(jiān)控系統(tǒng)的要求配置此欄

7 log_lock_waits 記錄語(yǔ)句執(zhí)行中的鎖等待時(shí)間

8 log_statement 對(duì)于什么語(yǔ)句進(jìn)行記錄，（這個(gè)與上面的無(wú)關(guān)，有語(yǔ)句審計(jì)的時(shí)候可能需要打開(kāi)這個(gè)開(kāi)關(guān)，進(jìn)行語(yǔ)句的收集，不建議使用all 否則對(duì)于系統(tǒng)的負(fù)擔(dān)太重，相當(dāng)于在MYSQL中開(kāi)啟genernal log）

實(shí)際上很多人在操作POSTGERSQL開(kāi)始的時(shí)候，是找不到日志的，因?yàn)槟J(rèn)PG的日志默認(rèn)是不打開(kāi)的，關(guān)鍵的參數(shù)在 logging_collector 默認(rèn)是off,所以安裝PG后的啟動(dòng)前的第一件事情就是要將這個(gè)設(shè)置變?yōu)镺N ，好讓PG從開(kāi)始就開(kāi)始記錄日志。

另外日志的定期清理方面PG比其他的開(kāi)源數(shù)據(jù)庫(kù)要做到好多了，因?yàn)椴簧偃硕嫉淖约簩?xiě)日志的rotate 和 clean up的腳本，PG 這里不需要，你只需要在 log_rotation_age中設(shè)置你要保留幾天的日志，同時(shí) log_truncate_on_rotation 設(shè)置為on 就可以了，這點(diǎn)是非常人性化的?；蛘吣阋部梢愿鶕?jù)日志的大小進(jìn)行設(shè)置如何拋棄他。

說(shuō)完這些，我們來(lái)看看實(shí)際當(dāng)中會(huì)遇到什么問(wèn)題，以一個(gè)案例

在搭建完P(guān)G后，系統(tǒng)上線前并無(wú)問(wèn)題，在系統(tǒng)上線后第二天，有人反饋PG的日志將系統(tǒng)的磁盤(pán)空間大量的占用，并且7 分鐘就產(chǎn)生一個(gè)日志文件，后續(xù)為了減少相關(guān)的日志的數(shù)量較快的增長(zhǎng)，做了如下修改

log_rotation_size = 100MB

將日志的容量以及重置設(shè)置的更大

修改完畢后，不重新系統(tǒng)，直接加載后，日志的增長(zhǎng)頻率已經(jīng)更改了。但日志的對(duì)磁盤(pán)空間的占用的問(wèn)題還是沒(méi)有解決。

打開(kāi)日志，系統(tǒng)記錄了大量如下的信息

罪魁禍?zhǔn)拙褪窍旅鎴D中的log_statement_stats 這個(gè)設(shè)置，將他打開(kāi)后，系統(tǒng)會(huì)根據(jù)每個(gè)SQL 產(chǎn)生一個(gè)語(yǔ)句的性能方面的統(tǒng)計(jì)信息，可以想象如果將他打開(kāi)可以看到每條語(yǔ)句在執(zhí)行中的狀態(tài)， duration 等等信息，但這樣就會(huì)產(chǎn)生大量的日志，經(jīng)過(guò)統(tǒng)計(jì)次系統(tǒng)1秒產(chǎn)生1MB的日志，（此系統(tǒng)每秒插入上百條數(shù)據(jù)），在關(guān)閉后，問(wèn)題解決。

所以看似一個(gè)日志的設(shè)置，如果不熟悉系統(tǒng)，也會(huì)造成類似的問(wèn)題，并且在緊急的狀態(tài)下，可能會(huì)用較長(zhǎng)的時(shí)間來(lái)解決。實(shí)際上日志系統(tǒng)還有一些其他的細(xì)節(jié)，例如時(shí)區(qū)的問(wèn)題，找機(jī)會(huì)可以在說(shuō)說(shuō)吧

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。