如何做好 openGauss 企業(yè)級部署

openGauss數(shù)據(jù)庫作為開源數(shù)據(jù)庫的后起之秀，這兩年開源社區(qū)蓬勃發(fā)展，越來越多的公司和企業(yè)加入到openGauss開源社區(qū)。作為純國產(chǎn)開源的關(guān)系型數(shù)據(jù)庫，當(dāng)前部分銀行已經(jīng)嘗試在生產(chǎn)應(yīng)用openGauss數(shù)據(jù)庫，同時也有很多合作伙伴在openGauss內(nèi)核的基礎(chǔ)上推出各自的商業(yè)版本。openGauss數(shù)據(jù)庫至今為止基本保持三月一次發(fā)版的節(jié)奏。每次發(fā)版都會發(fā)現(xiàn)內(nèi)容非常多，不僅包含大功能的新增和改進(jìn)，同時也有非常多的問題被修復(fù)?？梢哉fopenGauss開源社區(qū)的投入，并不遜色于傳統(tǒng)的大型商業(yè)數(shù)據(jù)庫公司。國內(nèi)幾家合作伙伴的加入和貢獻(xiàn)，也讓openGauss數(shù)據(jù)庫生態(tài)越來越好，這也給企業(yè)在生產(chǎn)使用openGauss數(shù)據(jù)庫帶來更大的信心。作為新的數(shù)據(jù)庫，如何做好企業(yè)及部署，這是值得探討的地方。這篇文章并不是一個細(xì)致的安裝教程，網(wǎng)上也不缺乏該類教程，而是結(jié)合商業(yè)數(shù)據(jù)庫應(yīng)用和部署的經(jīng)驗，討論下openGauss數(shù)據(jù)庫企業(yè)級應(yīng)用需求下需要考慮的方方面面。數(shù)據(jù)庫架構(gòu)設(shè)計

openGauss作為集中式的單機(jī)數(shù)據(jù)庫，這里的架構(gòu)設(shè)計主要是討論高可用怎么做，同城和異地容災(zāi)怎么做。本地高可用

傳統(tǒng)的數(shù)據(jù)庫本地高可用有兩種比較流行的方式：集中式存儲方式和數(shù)據(jù)庫復(fù)制方式。Db2和Oracle等商業(yè)數(shù)據(jù)庫的部署大部分都是采用集中式存儲的模式。而MySQL數(shù)據(jù)庫就基本都是通過數(shù)據(jù)庫復(fù)制的模式來實現(xiàn)高可用。集中式存儲

集中式存儲方案是目前企業(yè)級部署中應(yīng)用最廣泛也是最成熟的方案。數(shù)據(jù)庫的數(shù)據(jù)部署在存儲上，上層通過系統(tǒng)的HA工具監(jiān)控和切換。然而這種方式也有缺點(diǎn)。首先是外置存儲的性能和內(nèi)置SSD盤的性能差異在數(shù)據(jù)庫應(yīng)用場景對比還是比較明顯的。其次是磁盤數(shù)據(jù)的損壞需要通過數(shù)據(jù)庫恢復(fù)來修復(fù)，相對恢復(fù)時間較長。最后從部署成本來說，集中式存儲方案部署較重，需要存儲布線等。數(shù)據(jù)庫復(fù)制

數(shù)據(jù)庫復(fù)制方案是通過數(shù)據(jù)庫日志的物理或者邏輯同步，在備機(jī)實時重做主機(jī)的修改，從而保證主備數(shù)據(jù)庫的數(shù)據(jù)一致性。這也是一個非常成熟的方案。Db2和Oracle等商業(yè)數(shù)據(jù)庫都有基于數(shù)據(jù)庫日志物理同步的功能。MySQL的日志邏輯復(fù)制也應(yīng)用非常廣泛。這種方案下數(shù)據(jù)庫主機(jī)上的存儲采用內(nèi)置盤，主備的數(shù)據(jù)是完全隔離的，更好的利用了內(nèi)置盤的性能和做到了存儲上的隔離。openGauss數(shù)據(jù)庫也支持?jǐn)?shù)據(jù)庫日志的物理復(fù)制和邏輯復(fù)制。邏輯復(fù)制存在一個比較重大的缺點(diǎn)，就是對于大事務(wù)的數(shù)據(jù)回放性能不好。因此在openGauss數(shù)據(jù)庫的高可用設(shè)計中，數(shù)據(jù)庫日志物理同步是當(dāng)前最好的方案。官方的架構(gòu)圖也是推薦使用這種方式。openGauss數(shù)據(jù)庫提供了om工具來幫助部署和管理openGauss數(shù)據(jù)庫的主備集群節(jié)點(diǎn)。openGauss數(shù)據(jù)庫的物理復(fù)制支持一主多備和級聯(lián)備等功能，未來也會加入延時復(fù)制功能。openGauss的備機(jī)是支持只讀操作的，可以實現(xiàn)讀寫分離，減少主庫的讀負(fù)載。建議本地高可用就通過數(shù)據(jù)庫物理同步來實現(xiàn)。建議打開備機(jī)可讀，設(shè)置wal_level為hot_standby。為了保障數(shù)據(jù)一致性，synchronous_commit建議修改為remote_write或者remote_receive。如果只有一主一從的情況下，建議設(shè)置most_available_sync為on。最后通過第三方的高可用集群軟件來監(jiān)視openGauss的主從狀態(tài)，實現(xiàn)故障自動切換等高可用場景?？蛻舳嗽L問方式

openGauss數(shù)據(jù)庫主從架構(gòu)下，客戶端如何連接到主數(shù)據(jù)庫呢？又怎么做讀寫分離？這個時候就需要討論下客戶端連接數(shù)據(jù)庫的幾種方式：VIP，DNS和主機(jī)列表。因為openGauss數(shù)據(jù)庫的jdbc驅(qū)動里支持設(shè)置多個主機(jī)，并提供參數(shù)設(shè)置只連主節(jié)點(diǎn)還是只連備節(jié)點(diǎn)，這也應(yīng)對了讀寫分離的需求。VIP

傳統(tǒng)的VIP模式只能支持應(yīng)用連接到主節(jié)點(diǎn)上，從節(jié)點(diǎn)的讀請求是不太好設(shè)置的。增加讀VIP的管理對于高可用軟件來說就太復(fù)雜了。VIP管理還有一個限制是必須屬于同一網(wǎng)段。對于同城雙中心不能采用相同網(wǎng)段的情況下，VIP漂移就不能實現(xiàn)。DNS

DNS也具備高可用性，但是只能檢測到機(jī)器IP是否存在，不能檢測openGauss的服務(wù)，所以采用DNS的高可用相對來說不太適合數(shù)據(jù)庫來使用。主機(jī)列表

例如下面這個例子就是只連主庫的客戶端設(shè)置：url=jdbc:postgresql://:26000,:26000/?connectTimeout=5&targetServerType=master&tcpKeepAlive=true我比較偏向于采用主機(jī)列表的方式，通過配置客戶端參數(shù)，實現(xiàn)自動主庫發(fā)現(xiàn)，負(fù)載均衡，只讀從庫等各類應(yīng)用場景需求。這種方式也避免了VIP，DNS在不同架構(gòu)下的管理復(fù)雜性，相對更通用一些。缺點(diǎn)是增加了一點(diǎn)客戶端數(shù)據(jù)源配置的復(fù)雜性。同城容災(zāi)

數(shù)據(jù)庫級的同城容災(zāi)可能會分成不同的級別來實現(xiàn)。金融行業(yè)的同城數(shù)據(jù)中心一般都要求具備全量承載數(shù)據(jù)和業(yè)務(wù)的能力。數(shù)據(jù)庫實現(xiàn)同城容災(zāi)最主要目標(biāo)是最小化RPO和RTO指標(biāo)，在此基礎(chǔ)上可能還會有同城災(zāi)備數(shù)據(jù)庫的只讀訪問等需求。同城容災(zāi)的實現(xiàn)方式也有兩種主流模式：存儲復(fù)制和數(shù)據(jù)庫復(fù)制。優(yōu)缺點(diǎn)和本地高可用差不多。但是如果本地openGauss采用了內(nèi)置盤部署，那么也就不支持做存儲復(fù)制的容災(zāi)模式了。所以建議openGauss數(shù)據(jù)庫還是采用數(shù)據(jù)庫復(fù)制的方式。注意在設(shè)置synchronous_standby_names的時候要保證同城至少有一個節(jié)點(diǎn)處于數(shù)據(jù)同步狀態(tài)。這里稍微討論下同城容災(zāi)的幾個定位：1.同城是否需要保障RPO=0？金融行業(yè)的大部分需要做同城容災(zāi)的應(yīng)用都要求RPO=0，不能容忍同城切換丟失數(shù)據(jù)。因此在設(shè)計synchronous_standby_names的時候需要加上同城備機(jī)并設(shè)置成同步模式。然而雙中心間的網(wǎng)絡(luò)穩(wěn)定性顯然要比同中心要差很多，為了避免設(shè)置了強(qiáng)同步后，雙中心網(wǎng)絡(luò)抖動可能會影響主機(jī)性能，可以考慮設(shè)置most_available_sync參數(shù)為ON，丟失備機(jī)的情況下主機(jī)可以斷開備機(jī)并恢復(fù)工作。2.同城數(shù)據(jù)庫是否需要只讀訪問？數(shù)據(jù)庫的備機(jī)提供只讀訪問的能力，包括同城的數(shù)據(jù)庫備機(jī)。那么是否真的需要去啟用這個功能呢？從前端業(yè)務(wù)的性能考慮，顯然同機(jī)房訪問要比跨機(jī)房訪問要更快一些。而從后端數(shù)據(jù)庫的處理能力來說，需要只讀能力擴(kuò)展的需求，都是為了滿足減輕主庫的運(yùn)行壓力，并且還要求應(yīng)用能夠配置單獨(dú)的只讀數(shù)據(jù)源，從應(yīng)用層就解決好讀寫分離。在這些場景需求里，顯然本地的備機(jī)只讀訪問就可以解決這些問題，所以大概率是不需要升級到同城只讀訪問的性能擴(kuò)展需求的。只有一種情況下需要同城只讀訪問，那就是為了架構(gòu)的便利性，同城切換的便利性等需求。這種情況下并不是以擴(kuò)展性能為目的，而是以技術(shù)架構(gòu)方案的整體性設(shè)計需要。3.同城是否需要自動切換？這個問題一直是討論的比較多的地方。保守一點(diǎn)的想法是同城切換都是交給人工來決策的。激進(jìn)一點(diǎn)的想法是同城都保障不丟數(shù)據(jù)庫，當(dāng)然也可以自動切換，交給HA監(jiān)控并自動化切換修復(fù)多好。所以面對不同的選擇，這里對于同城的定位就不一樣，所涉及的HA架構(gòu)設(shè)計也很不相同。個人認(rèn)為除非同城雙中心定位完全無主次之分，否則大部分應(yīng)用還是偏向于運(yùn)行在主機(jī)房，這種情況下，同城切換適合交給人為決策，自動化平臺快速實現(xiàn)。異地容災(zāi)

異地容災(zāi)也需要分不同的數(shù)據(jù)保護(hù)類型。可能最關(guān)鍵的應(yīng)用也就是盡可能減少RPO和RTO。這種類型的關(guān)鍵應(yīng)用也是建議通過數(shù)據(jù)庫主從復(fù)制的方式來實現(xiàn)，只是異地的數(shù)據(jù)庫節(jié)點(diǎn)通常都是設(shè)置為異步模式。openGauss數(shù)據(jù)庫支持級聯(lián)備，也就是從一主多從的某個從庫上，配置一個級聯(lián)備機(jī)，指向異地容災(zāi)的數(shù)據(jù)庫從庫。這也是比較推薦的方式，減少主庫的壓力。用戶規(guī)劃設(shè)計這里主要討論下安裝部署里的操作系統(tǒng)用戶，數(shù)據(jù)庫用戶等規(guī)劃設(shè)計。系統(tǒng)用戶操作系統(tǒng)用戶主要是安裝openGauss的用戶和組，以及需要使用gsql客戶端訪問openGauss數(shù)據(jù)庫的操作系統(tǒng)用戶。例如華為的openGauss數(shù)據(jù)庫默認(rèn)采用omm用戶和dbgrp用戶組，這在華為的高斯分布式產(chǎn)品里都是這個設(shè)計的。我們使用openGauss的時候也延續(xù)了這個習(xí)慣。超級用戶omm操作系統(tǒng)用戶具有openGauss數(shù)據(jù)庫程序的訪問權(quán)限，能執(zhí)行g(shù)sql、gs_ctl等工具。而這些工具的權(quán)限一般是700，也就是說只有omm用戶能使用。而通常omm用戶訪問本地的openGauss是通過socket，可以使用超級用戶，還可以免密，因此這個用戶完全是交給系統(tǒng)管理員的，不適合交給用戶使用。應(yīng)用用戶那么如果應(yīng)用用戶需要使用gsql等工具怎么辦？這種情況下建議設(shè)計一個系統(tǒng)用戶appuser，并為它安裝一個單獨(dú)的gsql等工具客戶端，通過IO連接數(shù)據(jù)庫。數(shù)據(jù)庫用戶數(shù)據(jù)庫用戶也應(yīng)該分為幾種類型：超級管理員、監(jiān)控管理員、數(shù)據(jù)庫管理員和普通數(shù)據(jù)庫用戶。超級管理員一開始initdb的初始用戶就是超級管理員用戶，具有sysadmin的權(quán)限。這個用戶通常不會交給應(yīng)用來使用，甚至不應(yīng)該當(dāng)做超級管理員來使用。這個用戶只能是作為能夠登錄到這個操作系統(tǒng)上應(yīng)急的免密超級用戶。所以為了管理openGauss數(shù)據(jù)庫，我們還需要創(chuàng)建一個單獨(dú)的管理員用戶具備sysadmin角色權(quán)限。例如設(shè)計一個gsadmin用戶，在運(yùn)維工具平臺通過這個用戶遠(yuǎn)程管理所有的openGauss數(shù)據(jù)庫。createusergsadminwithsysadminpassword'xxxxxxxx'還有一種用戶是遠(yuǎn)程備份用戶，建議創(chuàng)建單獨(dú)的用戶并sysadmin角色權(quán)限。監(jiān)控管理員openGauss數(shù)據(jù)庫從2.0.0版本開始提供了monadmin角色。這個角色權(quán)限能夠訪問所有的系統(tǒng)視圖。因此對于監(jiān)控用戶，建議配置這個角色即可。createusermonadminwithmonadminpassword'xxxxxxxx'數(shù)據(jù)庫管理員openGauss的數(shù)據(jù)庫是相互隔離的。對于每一個獨(dú)立的數(shù)據(jù)庫，可以設(shè)置一個數(shù)據(jù)庫管理員角色的用戶，給予全庫的管理權(quán)限。grantallprivilegesondatabase<dbname>to<username>這種用戶通常也是作為應(yīng)用來連接的用戶，具備全庫的對象管理能力，也具備數(shù)據(jù)修改查詢能力。這是一種很常見的用法，很少有在應(yīng)用數(shù)據(jù)源配置連接用戶的時候還繼續(xù)做細(xì)致的權(quán)限分離。當(dāng)然數(shù)據(jù)庫權(quán)限管理是具備相關(guān)能力的。普通數(shù)據(jù)庫用戶

除了本應(yīng)用系統(tǒng)使用的數(shù)據(jù)庫管理員用戶，可能還存在類似跨系統(tǒng)訪問的特殊需求情況。例如抽取數(shù)據(jù)的用戶，只讀訪問的用戶等。這些用戶建議創(chuàng)建單獨(dú)的最小授權(quán)用戶。白名單在openGauss數(shù)據(jù)庫的目錄下，設(shè)計了pg_hba.conf配置文件，用來定義用戶訪問數(shù)據(jù)庫的方式，也可以稱作是白名單管理。定義了在什么訪問類型下，訪問哪個數(shù)據(jù)庫，是哪個用戶，從哪里來訪問，采用何種驗證方式。這些組合可以實現(xiàn)很復(fù)雜的白名單過濾規(guī)則。這種可以過濾IP的用戶訪問控制有點(diǎn)像mysql，但是又完全不一樣。openGauss里的數(shù)據(jù)庫用戶名對應(yīng)的就是一個用戶角色，不像mysql，如果用戶名里的IP不一樣，其實算是不同的用戶。不過從金融行業(yè)的實踐來看，數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器等在隔離的網(wǎng)絡(luò)區(qū)內(nèi)，主機(jī)間的訪問控制通過網(wǎng)絡(luò)來管理，基本不需要底層數(shù)據(jù)庫來實現(xiàn)復(fù)雜的管控。為了管理方便，不如全部放開數(shù)據(jù)庫級別的ip管控。下面這個例子使用gs_guc工具配置整個集群所有的白名單：gs_gucreload-Nall-Iall-h"host

all

all

0.0.0.0/0

sha256"翻譯過來就是任何IP基于host請求過來的所有用戶訪問所有數(shù)據(jù)庫都采用sha256加密算法驗證用戶。文件系統(tǒng)設(shè)計openGauss數(shù)據(jù)庫建議配置至少兩個獨(dú)立的文件系統(tǒng)。一個用來放數(shù)據(jù)庫，一個用來放數(shù)據(jù)庫運(yùn)行中產(chǎn)生的歸檔日志，診斷日志等。數(shù)據(jù)庫數(shù)據(jù)庫存放的路徑建議放在單獨(dú)的文件系統(tǒng)上。部分重要的業(yè)務(wù)系統(tǒng)也建議將在線日志pg_xlog放在單獨(dú)的文件系統(tǒng)上，與數(shù)據(jù)data分開。然而從實際情況來看，data和xlog采用不同的文件系統(tǒng)，除非底層的盤也是獨(dú)立的，性能是沒有什么區(qū)別的。因此暫時建議采用一個就可以了。診斷日志數(shù)據(jù)庫運(yùn)行中產(chǎn)生的診斷日志，審計日志，歸檔日志，core文件等，都是不影響數(shù)據(jù)庫運(yùn)行的，但是又持續(xù)不斷的產(chǎn)生的。因此需要單獨(dú)規(guī)劃一個文件系統(tǒng)來存放，同時做好這些日志的清理策略。這個文件系統(tǒng)也可以用來規(guī)劃存放腳本文件，備份文件，跑批文件等臨時文件。例如將歸檔日志路徑、審計日志路徑、core文件路徑和診斷日志路徑都設(shè)置到這個文件系統(tǒng)下面。gs_gucset

-c"archive_command='cp%p/gausslog/archive/%f'"

gs_gucset

-c"audit_directory='/gausslog/log/omm/pg_audit'"

gs_gucset

-c"bbox_dump_path='/gausslog/corefile'"

gs_gucset

-c"log_directory='/gausslog/log/omm/pg_log'"其他運(yùn)維設(shè)計規(guī)劃好了數(shù)據(jù)庫安裝，下一步是設(shè)計相關(guān)運(yùn)維需求方案。性能參數(shù)設(shè)置安裝完成之后最先需要的是根據(jù)業(yè)務(wù)負(fù)載需求設(shè)置相關(guān)參數(shù)。這些參數(shù)細(xì)節(jié)比較多，需要好好閱讀相關(guān)資料再做選擇。其中max_process_memory和shared_buffers是比較關(guān)鍵的內(nèi)存參數(shù)，建議按照操作系統(tǒng)內(nèi)存總量（數(shù)據(jù)庫獨(dú)占資源）的70%和50%來設(shè)置。增量檢查點(diǎn)和雙寫開關(guān)應(yīng)該打開。這個是openGauss相對于postgresql比較大的改進(jìn)機(jī)制，解決了全量檢查點(diǎn)的性能瓶頸問題。enable_opfusion開關(guān)也建議打開，對于高并發(fā)小事務(wù)的競爭會有改善。gs_gucset-c"cstore_buffers=128MB"

gs_gucset-c"enable_alarm=off"

gs_gucset-c"enable_delta_store=on"

gs_gucset-c"enable_double_write=on"

gs_gucset-c"enable_incremental_checkpoint=on"

gs_gucset-c"enable_wdr_snapshot=off"

gs_gucset-c"enable_xlog_prune=on"

gs_gucset-c"log_min_duration_statement=1s"

gs_gucset-c"maintenance_work_mem=1GB"

gs_gucset-c"max_connections=2000"

gs_gucset-c"max_files_per_process=10000"

gs_gucset-c"max_prepared_transactions=2000"

gs_gucset-c"session_timeout=0"

gs_gucset-c"shared_buffers=2GB"

gs_gucset-c"temp_buffers=128MB"

gs_gucset-c"update_lockwait_timeout=1min"

gs_gucset-c"wal_buffers=64MB"

gs_gucset-c"wdr_snapshot_interval=10min"

gs_gucset-c"work_mem=512MB"

gs_gucset-c"log_temp_files=100MB"

gs_gucset-c"enable_mergejoin=ON"

gs_gucset-c"enable_nestloop=ON"

gs_gucset-c"advance_xlog_file_num=10"

gs_gucset-c"pagewriter_sleep=1000ms"

gs_gucset-c"xloginsert_locks=50"

gs_gucset-c"lockwait_timeout=1min"

gs_gucset-c"enable_opfusion=off"

gs_gucset-c"max_process_memory=3GB"

自動管理為了降低DBA的運(yùn)維工作量，使用openGauss的過程里要充分利用好數(shù)據(jù)庫的自動管理機(jī)制。尤其是跟性能動態(tài)調(diào)整相關(guān)的機(jī)制。自動統(tǒng)計信息收集分析

openGauss數(shù)據(jù)庫內(nèi)部的執(zhí)行計劃有兩種選擇方式，基于規(guī)則和基于代價?；诖鷥r的這種方式依賴于數(shù)據(jù)庫的統(tǒng)計信息。數(shù)據(jù)庫的統(tǒng)計信息是由analyze命令采集的。除了人為發(fā)出analyze命令，openGauss內(nèi)部也提供了自動analyze的功能。建議打開autoanalyze和autovacuum的開關(guān)。自動清理

openGauss的存儲引擎還有一個比較特殊的地方，就是update和delete都會保留原元組，作為MVCC的基石。這種機(jī)制會不停產(chǎn)生死元組，并且一直占據(jù)表內(nèi)的空間。這種情況下需要vacuum命令來回收這些空間，后續(xù)的數(shù)據(jù)才能使用。openGauss提供了autovacuum機(jī)制，能夠根據(jù)表的數(shù)據(jù)變化量自動觸發(fā)vacuum機(jī)制，回收死元組。但是在vacuum受到MVCC機(jī)制影響，清理數(shù)據(jù)會檢查數(shù)據(jù)庫里最老的事務(wù)。因此除了打開autovacuum，還需要控制好數(shù)據(jù)庫內(nèi)的最長事務(wù)。所以需要監(jiān)控pg_stat_activity中xact_start不為空的事務(wù)，判斷長事務(wù)。如果遇到一直處于idleintransaction狀態(tài)的連接，一定要檢查處理。安全審計openGauss數(shù)據(jù)庫提供了安全審計功能，可以設(shè)置相關(guān)審計參數(shù)，將審計日志記錄下來，通過sql函數(shù)pg_query_audit查看審計記錄。下表展示了審計相關(guān)的配置項。其中DML操作和SELECT操作審計功能建議關(guān)閉，因為審計量太大了。配置項描述用戶登錄、注銷審計參數(shù)：audit_login_logout

默認(rèn)值為7，表示開啟用戶登錄、退出的審計功能。設(shè)置為0表示關(guān)閉用戶登錄、退出的審計功能。不推薦設(shè)置除0和7之外的值。數(shù)據(jù)庫啟動、停止、恢復(fù)和切換審計參數(shù)：audit_database_process

默認(rèn)值為1，表示開啟數(shù)據(jù)庫啟動、停止、恢復(fù)和切換的審計功能。用戶鎖定和解鎖審計參數(shù)：audit_user_locked

默認(rèn)值為1，表示開啟審計用戶鎖定和解鎖功能。用戶訪問越權(quán)審計參數(shù)：audit_user_violation

默認(rèn)值為0，表示關(guān)閉用戶越權(quán)操作審計功能。授權(quán)和回收權(quán)限審計參數(shù)：audit_grant_revoke

默認(rèn)值為1，表示開啟審計用戶權(quán)限授予和回收功能。數(shù)據(jù)庫對象的CREATE，ALTER，DROP操作審計參數(shù)：audit_system_object

默認(rèn)值為12295，表示只對DATABASE、SCHEMA、USER、DATASOURCE這四類數(shù)據(jù)庫對象的CREATE、ALTER、DROP操作進(jìn)行審計。具體表的INSERT、UPDATE和DELETE操作審計參數(shù)：audit_dml_state

默認(rèn)值為0，表示關(guān)閉具體表的DML操作（SELECT除外）審計功能。SELECT操作審計參數(shù)：audit_dml_state_select

默認(rèn)值為0，表示關(guān)閉SELECT操作審計功能。COPY審計參數(shù)：audit_copy_exec

默認(rèn)值為0，表示關(guān)閉copy操作審計功能。存儲過程和自定義函數(shù)的執(zhí)行審計參數(shù)：audit_function_exec

默認(rèn)值為0，表示不記錄存儲過程和自定義函數(shù)的執(zhí)行審計日志。SET審計參數(shù)：audit_set_parameter

默認(rèn)值為1，表示記錄set操作審計日志如果需要針對特殊用戶進(jìn)行SQL級別的審計，可以使用AUDITPOLICY統(tǒng)一審計方式。打開enable_security_policy開關(guān)統(tǒng)一審計策略才可以生效。統(tǒng)一審計默認(rèn)輸出節(jié)點(diǎn)的rsyslog日志中，在操作系統(tǒng)后臺服務(wù)配置文件/etc/rsyslog.conf中添加代碼：local0.*/var/log/localmessages執(zhí)行如下命令:sudotouch/var/log/localmessages

sudochmod600localmessages

sudosystemctlrestartrsyslog然后通過創(chuàng)建AUDITPOLICY實現(xiàn)。CREATEAUDITPOLICY[IFNOTEXISTS]policy_name{{privilege_audit_clause|access_audit_clause}[filter_group_clause][ENABLE|DISABLE]};例如僅審計user1用戶的iud操作：CREATEAUDITPOLICYadt1ACCESSINSERT,UPDATE,DELE