數據庫連接

RDS for PostgreSQL是進程(cheng)架構，每(mei)個客戶端連接都(dou)對應一個后端服務進程(cheng)。

• 根據(ju)業務的復雜度，合理配(pei)置“max_connections”，例如(ru)，參考pgtune：

WEB應用：“max_connections ”配(pei)置為(wei)200

OLTP應用：“max_connections”配置(zhi)為300

數據倉庫：“max_connections”配置為40

桌面應用：“max_connections”配置(zhi)為20

混(hun)合應用：“max_connections”配置為(wei)100

• 根據業(ye)務(wu)需要限(xian)制單個用戶的最大連接數。

ALTER ROLE xxx CONNECTION LIMIT xxx;

• 保持(chi)合理的(de)活(huo)躍(yue)連(lian)接數(shu)，建(jian)議(yi)活(huo)躍(yue)連(lian)接數(shu)為CPU數(shu)量的(de)2~3倍。

• 避(bi)免長(chang)事務(wu)，長(chang)事務(wu)會阻塞autovacuum等(deng)，導致(zhi)出現性能問題。

• 避免長(chang)連接，長(chang)連接的緩(huan)存可能(neng)較大，導致(zhi)內(nei)存不足，建議定期釋放長(chang)連接。

• 檢查應用程(cheng)(cheng)序框架(jia)，避免應用程(cheng)(cheng)序自動begin事務，但不做任(ren)何(he)操作。

只讀實例

• 避免長事(shi)務(wu)，長事(shi)務(wu)容(rong)易(yi)導致(zhi)查詢(xun)沖突，影(ying)響回放。

• 對實時性(xing)有要求(qiu)的(de)實例，建議配置“hot_standby_feedback”，同時根據業務(wu)設置“max_standby_streaming_delay”為合理(li)的(de)值。

• 監控長(chang)事務(wu)、長(chang)連(lian)接和復制(zhi)延遲，出現問(wen)題(ti)及時處理(li)。

• 只讀實例(li)為單(dan)節(jie)點，不提供高(gao)可用(yong)能力，連接只讀實例(li)的應(ying)用(yong)程序應(ying)該具備(bei)切換到其(qi)他(ta)節(jie)點的能力。

可靠性、可用性

• 生產數據庫的(de)實例類(lei)型(xing)務必選擇主備類(lei)型(xing)。

• 生產數(shu)據庫的CPU、內存、磁盤要有一定的冗(rong)余，正(zheng)常使用保持在70%以(yi)下，防止(zhi)出現OOM、磁盤滿等異常問題。

• 將主、備(bei)機部署在不同(tong)可用區(qu)內，增加(jia)可用性。

• 將(jiang)周(zhou)期性備份設(she)置到業務低峰期，并且不要(yao)關閉全量備份。

• 建(jian)議將主備的復制模式設(she)置(zhi)為“異步”，防止備機故障阻塞主機業務。

• 業務上需要關注臨(lin)時(shi)文件(jian)(jian)大小與生成(cheng)速(su)率指標。若臨(lin)時(shi)文件(jian)(jian)生成(cheng)過多(duo)，會(hui)對性(xing)能產生影響，并(bing)且(qie)會(hui)拖慢數據(ju)庫啟動，造成(cheng)業務不(bu)可(ke)用。

• 業(ye)務(wu)(wu)上應避免在(zai)單(dan)個實例(li)創(chuang)建大量對(dui)象。一般而言單(dan)個實例(li)表個數(shu)(shu)不宜超過(guo)2萬(wan)，單(dan)個數(shu)(shu)據(ju)庫(ku)中表個數(shu)(shu)不宜超過(guo)4千。防止在(zai)數(shu)(shu)據(ju)庫(ku)啟動(dong)時，由于掃描(miao)表文件(jian)耗(hao)時過(guo)久，導致業(ye)務(wu)(wu)不可用(yong)。

邏輯復制

• 創建的邏(luo)輯(ji)復制槽(cao)名(ming)需要在40個字節長度以下，否則可(ke)能導(dao)致(zhi)全量備份失(shi)敗。

• 使(shi)用邏(luo)輯(ji)復制時，注意刪(shan)除(chu)不(bu)再使(shi)用的復制槽，防止數(shu)據庫(ku)膨脹(zhang)。

• 使用普通邏輯復(fu)制槽時，注意主(zhu)備(bei)倒(dao)換（規格變更、小版(ban)本(ben)升級或主(zhu)機故(gu)障(zhang)等(deng)場景(jing)可(ke)能發生主(zhu)備(bei)倒(dao)換）后(hou)復(fu)制槽會丟失(shi)，需要再次創建復(fu)制槽。

• RDS for PostgreSQL 12.6及以上的(de)小版(ban)本、13和14的(de)所有小版(ban)本使用具備(bei)故障轉移功能(neng)復(fu)制槽(cao)，避(bi)免(mian)主(zhu)備(bei)倒換(huan)或數據庫重啟后復(fu)制槽(cao)丟失(shi)。

• 使用(yong)邏輯(ji)復(fu)制(zhi)時，業(ye)務盡量避免(mian)長事務，廢棄的兩階段事務需要及時提(ti)交，防(fang)止WAL日志(zhi)積壓，占用(yong)過(guo)高磁(ci)盤空間。

• 使用邏(luo)輯復制時，盡量避(bi)免大量使用子事務（事務內使用savepoint、exception等），防止(zhi)造成過高的內存(cun)占用。

• 使用DRS等(deng)服(fu)務進行數據同步、遷移時，對于(yu)長期無(wu)業務的庫，建議刪除其中(zhong)包含的邏(luo)輯復制槽，或添加心跳表來定(ding)期推進復制槽位點(dian)，避免WAL日志(zhi)積(ji)壓。

數據庫年齡

• 數據庫年齡的概念：

數據(ju)庫(ku)年齡是(shi)PostgreSQL特有的概念，指(zhi)的是(shi)數據(ju)庫(ku)中最舊(jiu)和最新兩個事務ID的差值。

由于(yu)RDS for PostgreSQL的MVCC機制(zhi)，數據(ju)(ju)庫(ku)年(nian)(nian)齡最大為(wei)20億，當年(nian)(nian)齡耗(hao)盡，數據(ju)(ju)庫(ku)會強(qiang)制(zhi)關閉，只能聯(lian)系技術支持來執行(xing)清(qing)理操作。

可以(yi)通過以(yi)下SQL查看當前數據庫年齡：

select datname, age(datfrozenxid) from pg_database;

• 建議通過“db_max_age”CES指標來監控數據庫年齡，告警閾(yu)值設(she)置(zhi)為10億。

穩定性

• 對于(yu)兩階(jie)段提交(jiao)的(de)事(shi)務，要(yao)及時提交(jiao)或回滾，防(fang)止導(dao)致數據庫膨脹。

• 選擇業務低峰期變更表(biao)結構，如添加字段，索引操(cao)作。

• 業務高峰期創(chuang)(chuang)建索引時，建議使用CONCURRENTLY語法，并行(xing)創(chuang)(chuang)建索引，不堵塞表的DML。

• 業務高峰期修改表結構，要(yao)提前進(jin)行測試，防(fang)止表的REWRITE。

• DDL操(cao)作(zuo)需要(yao)設置鎖等待超時時間，防止阻(zu)塞(sai)相關表的操(cao)作(zuo)。

• 單個數據庫(ku)庫(ku)容量超過2T，需要考慮(lv)分庫(ku)。

• 頻繁訪問的(de)表(biao)，單表(biao)記錄(lu)過(guo)2000萬，或超過(guo)10GB，需要(yao)考慮(lv)分表(biao)或創建分區。

• PostgreSQL的(de)備庫、只讀(du)(du)庫單進程回放WAL日志，最(zui)大回放速(su)度為50 MB/s~70 MB/s，因此需要(yao)控制(zhi)(zhi)主庫數據寫入壓力在50 MB/s以下，避免備機、只讀(du)(du)復制(zhi)(zhi)異常(chang)。

日常運維

• 在實例管(guan)理界(jie)面下載慢SQL，及時關注并解決(jue)性能問題。

• 定期關注數據(ju)庫的資(zi)源使用(yong)情況，若(ruo)業(ye)務(wu)(wu)壓力存在較大波(bo)動，建(jian)議(yi)配置資(zi)源告警，必要(yao)時(shi)擴充規(gui)格。業(ye)務(wu)(wu)寫入(ru)壓力過(guo)大會導致數據(ju)庫重(zhong)啟恢復過(guo)程(cheng)緩慢，影響(xiang)業(ye)務(wu)(wu)可用(yong)性。

• 刪除和修改記錄時，需要先執(zhi)行SELECT，確認無誤才能提交執(zhi)行。

• 大批量數據刪除、更(geng)新后，應對(dui)被操作(zuo)表執行VACUUM。

• 關注可(ke)用(yong)復制(zhi)槽(cao)數(shu)以及(ji)創建的復制(zhi)槽(cao)，請始終保持至(zhi)少有一個空余的復制(zhi)槽(cao)可(ke)供數(shu)據(ju)庫(ku)備份(fen)使用(yong)，否(fou)則數(shu)據(ju)庫(ku)備份(fen)會失敗(bai)。

• 及時(shi)清理不再(zai)使用的復(fu)制(zhi)槽，防止(zhi)復(fu)制(zhi)槽阻塞日志回收。

• 不(bu)要使用不(bu)記(ji)錄日志的(de)表（UNLOGGED TABLE），因為該表的(de)數(shu)據(ju)會(hui)在數(shu)據(ju)庫異常（如OOM、底層故障等）或發生主(zhu)備倒(dao)換(huan)后丟(diu)失。

• 盡量(liang)避(bi)免對系(xi)統表做vacuum full操作，若有必要建議使用vacuum；否(fou)則執行(xing)vacuum full，并重(zhong)啟數據庫后，可能導(dao)致數據庫長(chang)時間無(wu)法連(lian)接。

安全

• 盡(jin)量避(bi)免數據庫被公(gong)網訪問，公(gong)網連接時必(bi)須綁(bang)定彈性公(gong)網IP，設置合適的白名單。

• 盡(jin)量使用SSL連接，保證連接的安全(quan)性。