【摘要】 openGauss數(shù)據(jù)庫作為開源數(shù)據(jù)庫的后起之秀，這兩年蓬勃發(fā)展，關(guān)于其細(xì)致的安裝教程，網(wǎng)上并不缺少，但其 作為新的數(shù)據(jù)庫，如何做好企業(yè)及部署，這是值得探討 的方向。 本文結(jié)合商業(yè)數(shù)據(jù)庫應(yīng)用和部署的經(jīng)驗，討論openGauss數(shù)據(jù)庫企業(yè)級應(yīng)用需求下需要考慮的方方面面，具有獨到的參考價值。

【作者】孔再華， 具有豐富的數(shù)據(jù)庫環(huán)境問題診斷和性能調(diào)優(yōu)的經(jīng)驗。在數(shù)據(jù)庫同城雙活，集群，多分區(qū)，分布式等項目實施上具有豐富的經(jīng)驗?，F(xiàn)任職于某股份制銀行科技部，工作致力于數(shù)據(jù)庫同城雙活架構(gòu)建設(shè)，數(shù)據(jù)庫分布式架構(gòu)建設(shè)和數(shù)據(jù)庫智能運維（AIOps）方向。對于如何將AI技術(shù)運用在運維領(lǐng)域具有濃厚的興趣和創(chuàng)新熱情。

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)容非常多，不僅包含大功能的新增和改進，同時也有非常多的問題被修復(fù)?？梢哉fopenGauss開源社區(qū)的投入，并不遜色于傳統(tǒng)的大型商業(yè)數(shù)據(jù)庫公司。國內(nèi)幾家合作伙伴的加入和貢獻，也讓openGauss數(shù)據(jù)庫生態(tài)越來越好，這也給企業(yè)在生產(chǎn)使用openGauss數(shù)據(jù)庫帶來更大的信心。

數(shù)據(jù)庫架構(gòu)設(shè)計  

openGauss作為集中式的單機數(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)控和切換。然而這種方式也有缺點。首先是外置存儲的性能和內(nèi)置SSD盤的性能差異在數(shù)據(jù)庫應(yīng)用場景對比還是比較明顯的。其次是磁盤數(shù)據(jù)的損壞需要通過數(shù)據(jù)庫恢復(fù)來修復(fù)，相對恢復(fù)時間較長。最后從部署成本來說，集中式存儲方案部署較重，需要存儲布線等。

數(shù)據(jù)庫復(fù)制  

數(shù)據(jù)庫復(fù)制方案是通過數(shù)據(jù)庫日志的物理或者邏輯同步，在備機實時重做主機的修改，從而保證主備數(shù)據(jù)庫的數(shù)據(jù)一致性。這也是一個非常成熟的方案。Db2和Oracle等商業(yè)數(shù)據(jù)庫都有基于數(shù)據(jù)庫日志物理同步的功能。MySQL的日志邏輯復(fù)制也應(yīng)用非常廣泛。這種方案下數(shù)據(jù)庫主機上的存儲采用內(nèi)置盤，主備的數(shù)據(jù)是完全隔離的，更好的利用了內(nèi)置盤的性能和做到了存儲上的隔離。

openGauss數(shù)據(jù)庫也支持?jǐn)?shù)據(jù)庫日志的物理復(fù)制和邏輯復(fù)制。邏輯復(fù)制存在一個比較重大的缺點，就是對于大事務(wù)的數(shù)據(jù)回放性能不好。因此在openGauss數(shù)據(jù)庫的高可用設(shè)計中，數(shù)據(jù)庫日志物理同步是當(dāng)前最好的方案。

官方的架構(gòu)圖也是推薦使用這種方式。openGauss數(shù)據(jù)庫提供了om工具來幫助部署和管理openGauss數(shù)據(jù)庫的主備集群節(jié)點。openGauss數(shù)據(jù)庫的物理復(fù)制支持一主多備和級聯(lián)備等功能，未來也會加入延時復(fù)制功能。openGauss的備機是支持只讀操作的，可以實現(xiàn)讀寫分離，減少主庫的讀負(fù)載。

建議本地高可用就通過數(shù)據(jù)庫物理同步來實現(xiàn)。建議打開備機可讀，設(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)故障自動切換等高可用場景。

客戶端訪問方式  

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

VIP  

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

DNS  

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

主機列表  

例如下面這個例子就是只連主庫的客戶端設(shè)置：

url=jdbc:postgresql:// :26000, :26000/ ?connectTimeout=5&targetServerType=master&tcpKeepAlive=true

我比較偏向于采用主機列表的方式，通過配置客戶端參數(shù)，實現(xiàn)自動主庫發(fā)現(xiàn)，負(fù)載均衡，只讀從庫等各類應(yīng)用場景需求。這種方式也避免了VIP，DNS在不同架構(gòu)下的管理復(fù)雜性，相對更通用一些。缺點是增加了一點客戶端數(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)缺點和本地高可用差不多。但是如果本地openGauss采用了內(nèi)置盤部署，那么也就不支持做存儲復(fù)制的容災(zāi)模式了。所以建議openGauss數(shù)據(jù)庫還是采用數(shù)據(jù)庫復(fù)制的方式。注意在設(shè)置synchronous_standby_names的時候要保證同城至少有一個節(jié)點處于數(shù)據(jù)同步狀態(tài)。

這里稍微討論下同城容災(zāi)的幾個定位：

1.同城是否需要保障RPO=0？

金融行業(yè)的大部分需要做同城容災(zāi)的應(yīng)用都要求RPO=0，不能容忍同城切換丟失數(shù)據(jù)。因此在設(shè)計synchronous_standby_names的時候需要加上同城備機并設(shè)置成同步模式。然而雙中心間的網(wǎng)絡(luò)穩(wěn)定性顯然要比同中心要差很多，為了避免設(shè)置了強同步后，雙中心網(wǎng)絡(luò)抖動可能會影響主機性能，可以考慮設(shè)置most_available_sync參數(shù)為ON，丟失備機的情況下主機可以斷開備機并恢復(fù)工作。

2.同城數(shù)據(jù)庫是否需要只讀訪問？

數(shù)據(jù)庫的備機提供只讀訪問的能力，包括同城的數(shù)據(jù)庫備機。那么是否真的需要去啟用這個功能呢？從前端業(yè)務(wù)的性能考慮，顯然同機房訪問要比跨機房訪問要更快一些。而從后端數(shù)據(jù)庫的處理能力來說，需要只讀能力擴展的需求，都是為了滿足減輕主庫的運行壓力，并且還要求應(yīng)用能夠配置單獨的只讀數(shù)據(jù)源，從應(yīng)用層就解決好讀寫分離。在這些場景需求里，顯然本地的備機只讀訪問就可以解決這些問題，所以大概率是不需要升級到同城只讀訪問的性能擴展需求的。只有一種情況下需要同城只讀訪問，那就是為了架構(gòu)的便利性，同城切換的便利性等需求。這種情況下并不是以擴展性能為目的，而是以技術(shù)架構(gòu)方案的整體性設(shè)計需要。

3.同城是否需要自動切換？

這個問題一直是討論的比較多的地方。保守一點的想法是同城切換都是交給人工來決策的。激進一點的想法是同城都保障不丟數(shù)據(jù)庫，當(dāng)然也可以自動切換，交給HA監(jiān)控并自動化切換修復(fù)多好。所以面對不同的選擇，這里對于同城的定位就不一樣，所涉及的HA架構(gòu)設(shè)計也很不相同。個人認(rèn)為除非同城雙中心定位完全無主次之分，否則大部分應(yīng)用還是偏向于運行在主機房，這種情況下，同城切換適合交給人為決策，自動化平臺快速實現(xiàn)。

異地容災(zāi)  

異地容災(zāi)也需要分不同的數(shù)據(jù)保護類型?？赡茏铌P(guān)鍵的應(yīng)用也就是盡可能減少RPO和RTO。這種類型的關(guān)鍵應(yīng)用也是建議通過數(shù)據(jù)庫主從復(fù)制的方式來實現(xiàn)，只是異地的數(shù)據(jù)庫節(jié)點通常都是設(shè)置為異步模式。

用戶規(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，并為它安裝一個單獨的gsql等工具客戶端，通過IO連接數(shù)據(jù)庫。

數(shù)據(jù)庫用戶

數(shù)據(jù)庫用戶也應(yīng)該分為幾種類型：超級管理員、監(jiān)控管理員、數(shù)據(jù)庫管理員和普通數(shù)據(jù)庫用戶。

超級管理員

一開始initdb的初始用戶就是超級管理員用戶，具有sysadmin126459646的權(quán)限。這個用戶通常不會交給應(yīng)用來使用，甚至不應(yīng)該當(dāng)做超級管理員來使用。這個用戶只能是作為能夠登錄到這個操作系統(tǒng)上應(yīng)急的免密超級用戶。

所以為了管理openGauss數(shù)據(jù)庫，我們還需要創(chuàng)建一個單獨的管理員用戶具備sysadmin126459646角色權(quán)限。例如設(shè)計一個gsadmin126459646用戶，在運維工具平臺通過這個用戶遠(yuǎn)程管理所有的openGauss數(shù)據(jù)庫。

create user gsadmin126459646 with sysadmin126459646 password ’xxxxxxxx’

還有一種用戶是遠(yuǎn)程備份用戶，建議創(chuàng)建單獨的用戶并sysadmin126459646角色權(quán)限。

監(jiān)控管理員

openGauss數(shù)據(jù)庫從2.0.0版本開始提供了monadmin126459646角色。這個角色權(quán)限能夠訪問所有的系統(tǒng)視圖。因此對于監(jiān)控用戶，建議配置這個角色即可。

create user monadmin126459646 with monadmin126459646 password ’xxxxxxxx’

數(shù)據(jù)庫管理員

openGauss的數(shù)據(jù)庫是相互隔離的。對于每一個獨立的數(shù)據(jù)庫，可以設(shè)置一個數(shù)據(jù)庫管理員角色的用戶，給予全庫的管理權(quán)限。

grant all privileges on database <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)建單獨的最小授權(quán)用戶。

白名單

在openGauss數(shù)據(jù)庫的目錄下，設(shè)計了pg_hba.conf配置文件，用來定義用戶訪問數(shù)據(jù)庫的方式，也可以稱作是白名單管理。定義了在什么訪問類型下，訪問哪個數(shù)據(jù)庫，是哪個用戶，從哪里來訪問，采用何種驗證方式。這些組合可以實現(xiàn)很復(fù)雜的白名單過濾規(guī)則。這種可以過濾IP的用戶訪問控制有點像mysql，但是又完全不一樣。openGauss里的數(shù)據(jù)庫用戶名對應(yīng)的就是一個用戶角色，不像mysql，如果用戶名里的IP不一樣，其實算是不同的用戶。

不過從金融行業(yè)的實踐來看，數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器等在隔離的網(wǎng)絡(luò)區(qū)內(nèi)，主機間的訪問控制通過網(wǎng)絡(luò)來管理，基本不需要底層數(shù)據(jù)庫來實現(xiàn)復(fù)雜的管控。為了管理方便，不如全部放開數(shù)據(jù)庫級別的ip管控。下面這個例子使用gs_guc工具配置整個集群所有的白名單：

gs_guc reload -N all -I all -h "host  all  all  0.0.0.0/0  sha256"

文件系統(tǒng)設(shè)計

openGauss數(shù)據(jù)庫建議配置至少兩個獨立的文件系統(tǒng)。一個用來放數(shù)據(jù)庫，一個用來放數(shù)據(jù)庫運行中產(chǎn)生的歸檔日志，診斷日志等。

數(shù)據(jù)庫

數(shù)據(jù)庫存放的路徑建議放在單獨的文件系統(tǒng)上。部分重要的業(yè)務(wù)系統(tǒng)也建議將在線日志pg_xlog放在單獨的文件系統(tǒng)上，與數(shù)據(jù)data分開。然而從實際情況來看，data和xlog采用不同的文件系統(tǒng)，除非底層的盤也是獨立的，性能是沒有什么區(qū)別的。因此暫時建議采用一個就可以了。

診斷日志

數(shù)據(jù)庫運行中產(chǎn)生的診斷日志，審計日志，歸檔日志，core文件等，都是不影響數(shù)據(jù)庫運行的，但是又持續(xù)不斷的產(chǎn)生的。因此需要單獨規(guī)劃一個文件系統(tǒng)來存放，同時做好這些日志的清理策略。這個文件系統(tǒng)也可以用來規(guī)劃存放腳本文件，備份文件，跑批文件等臨時文件。

例如將歸檔日志路徑、審計日志路徑、core文件路徑和診斷日志路徑都設(shè)置到這個文件系統(tǒng)下面。

其他運維設(shè)計

規(guī)劃好了數(shù)據(jù)庫安裝，下一步是設(shè)計相關(guā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ù)庫獨占資源）的70%和50%來設(shè)置。

增量檢查點和雙寫開關(guān)應(yīng)該打開。這個是openGauss相對于postgresql比較大的改進機制，解決了全量檢查點的性能瓶頸問題。enable_opfusion開關(guān)也建議打開，對于高并發(fā)小事務(wù)的競爭會有改善。

gs_guc set -c "cstore_buffers = 128MB" gs_guc set -c "enable_alarm = off" gs_guc set -c "enable_delta_store = on" gs_guc set -c "enable_double_write = on" gs_guc set -c "enable_incremental_checkpoint = on" gs_guc set -c "enable_wdr_snapshot = off" gs_guc set -c "enable_xlog_prune = on" gs_guc set -c "log_min_duration_statement = 1s" gs_guc set -c "maintenance_work_mem=1GB" gs_guc set -c "max_connections = 2000" gs_guc set -c "max_files_per_process = 10000" gs_guc set -c "max_prepared_transactions = 2000" gs_guc set -c "session_timeout = 0" gs_guc set -c "shared_buffers = 2GB" gs_guc set -c "temp_buffers = 128MB" gs_guc set -c "update_lockwait_timeout = 1min" gs_guc set -c "wal_buffers = 64MB" gs_guc set -c "wdr_snapshot_interval = 10min" gs_guc set -c "work_mem = 512MB" gs_guc set -c "log_temp_files = 100MB" gs_guc set -c "enable_mergejoin = ON" gs_guc set -c "enable_nestloop = ON" gs_guc set -c "advance_xlog_file_num = 10" gs_guc set -c "pagewriter_sleep = 1000ms" gs_guc set -c "xloginsert_locks = 50" gs_guc set -c "lockwait_timeout = 1min" gs_guc set -c "enable_opfusion = off" gs_guc set -c "max_process_memory=3GB"              

自動管理

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

自動統(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的基石。這種機制會不停產(chǎn)生死元組，并且一直占據(jù)表內(nèi)的空間。這種情況下需要vacuum命令來回收這些空間，后續(xù)的數(shù)據(jù)才能使用。openGauss提供了autovacuum機制，能夠根據(jù)表的數(shù)據(jù)變化量自動觸發(fā)vacuum機制，回收死元組。但是在vacuum受到MVCC機制影響，清理數(shù)據(jù)會檢查數(shù)據(jù)庫里最老的事務(wù)。因此除了打開autovacuum，還需要控制好數(shù)據(jù)庫內(nèi)的最長事務(wù)。所以需要監(jiān)控pg_stat_activity中xact_start不為空的事務(wù)，判斷長事務(wù)。如果遇到一直處于idle in transaction狀態(tài)的連接，一定要檢查處理。

安全審計

openGauss數(shù)據(jù)庫提供了安全審計功能，可以設(shè)置相關(guān)審計參數(shù)，將審計日志記錄下來，通過sql函數(shù)pg_query_audit查看審計記錄。

下表展示了審計相關(guān)的配置項。其中DML操作和SELECT操作審計功能建議關(guān)閉，因為審計量太大了。

如果需要針對特殊用戶進行SQL級別的審計，可以使用AUDIT POLICY統(tǒng)一審計方式。 打開enable_security_policy開關(guān)統(tǒng)一審計策略才可以生效。

統(tǒng)一審計默認(rèn)輸出節(jié)點的rsyslog日志中，在操作系統(tǒng)后臺服務(wù)配置文件/etc/rsyslog.conf中添加代碼：

local0.* /var/log/localmessages

執(zhí)行如下命令:

sudo touch /var/log/localmessages                             sudo chmod 600 localmessages                             sudo systemctl restart rsyslog

然后通過創(chuàng)建 AUDIT POLICY實現(xiàn)。

CREATE AUDIT POLICY [ IF NOT EXISTS ] policy_name { { privilege_audit_clause | access_audit_clause } [ filter_group_clause ] [ ENABLE | DISABLE ] };

例如僅審計user1用戶的iud操作：

CREATE AUDIT POLICY adt1 ACCESS INSERT,UPDATE,DELETE FILTER ON ROLES(user1);

監(jiān)控告警  

對于企業(yè)級的數(shù)據(jù)庫部署運維，監(jiān)控告警和應(yīng)急處理是最重要的。對于openGauss的監(jiān)控告警需要達到的目標(biāo)是能夠準(zhǔn)確發(fā)現(xiàn)問題并告警，能夠快速基于監(jiān)控數(shù)據(jù)分析根因并處理。為了實現(xiàn)這個目標(biāo)，建議openGauss數(shù)據(jù)庫的監(jiān)控一方面要全面采集性能和狀態(tài)指標(biāo)，另一方面對于關(guān)鍵指標(biāo)實現(xiàn)準(zhǔn)確告警。

監(jiān)控  

openGauss提供了很多監(jiān)控視圖。特別是dbe_perf模式下的監(jiān)控視圖，內(nèi)容包括OS、Instance、Memory、File、Object、Workload、Session/Thread、Transaction、Query、Cache/IO、Utility、Lock、Wait Events、Configuration、Operator和Workload Manager等對象的監(jiān)控。這些監(jiān)控視圖也是WDR報告的快照來源。建議統(tǒng)一采集這些性能快照視圖數(shù)據(jù)，通過智能運維管理和分析。

告警  

相對于監(jiān)控數(shù)據(jù)采集的全面性，告警指標(biāo)需要挑選全局有意義的對象。重要的告警有監(jiān)控數(shù)據(jù)庫狀態(tài)、主從復(fù)制狀態(tài)、在線會話數(shù)量、等待會話數(shù)量、長事務(wù)、長SQL、死鎖、回滾語句數(shù)量等。

備份恢復(fù)  

openGauss數(shù)據(jù)庫支持的備份方式還是比較全面的。而企業(yè)級的數(shù)據(jù)庫在這方面要求也很高。一方面為了出問題盡快恢復(fù)，數(shù)據(jù)庫定期備份策略都比較激進，另一方面?zhèn)浞葸^程還要盡量減少性能影響和資源占用。例如銀行一般每天都會備份全量數(shù)據(jù)庫，時刻備份歸檔日志，為了減少性能影響，備份會選擇從庫執(zhí)行。如果是遠(yuǎn)程備份，那么還會采用單獨的備份網(wǎng)段，與生產(chǎn)業(yè)務(wù)網(wǎng)隔離。

結(jié)束語

其實做好openGauss企業(yè)級部署，就是拿之前對于Db2和Oracle的運維標(biāo)準(zhǔn)來建設(shè)openGauss數(shù)據(jù)庫的運維體系。openGauss數(shù)據(jù)庫技術(shù)特點與這些商業(yè)數(shù)據(jù)庫相比差別不大，當(dāng)前欠缺的也只是生態(tài)和產(chǎn)品成熟性。相信這兩方面會越來越好，因此我對于openGauss數(shù)據(jù)庫在企業(yè)中的應(yīng)用前景非常看好，也希望其盡快成為一個合格的國產(chǎn)替代品。

點擊文末 閱讀原文 ，可以到社區(qū)原文后留言交流

覺得本文有用，請 轉(zhuǎn)發(fā)、點贊 或點擊 “賞” ，讓更多同行看到

點擊閱讀原文關(guān)注社區(qū)     “數(shù)據(jù)庫” 技術(shù)主題   ，將會不斷更新優(yōu)質(zhì)資料、文章，您也可以前往提出疑難問題，與同行切磋交流。地址： https://www.talkwithtrend.com/Channel/597

*本公眾號所發(fā)布內(nèi)容僅代表作者觀點，不代表社區(qū)立場