數據庫狀態監控活動
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 列出當前狀態為down的Segment。如果有任何行被返回，就會生成一個警告或者告警。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
在postgres數據庫中運行下例查詢： SELECT * FROM gp_segment_configuration WHERE status <> 'u'; |
如果該查詢返回任何行，按照這些步驟來糾正問題：
|
| 檢查當前處於改變跟蹤模式的Segment。如果任何行被返回，應該生成一個警告或者告警。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
在
postgres數據庫中執行下列查詢：
SELECT * FROM gp_segment_configuration WHERE mode = 'c'; |
如果該查詢返回任何行，按這些步驟來糾正問題：
|
| 檢查當前在重新同步的Segment。如果有行被返回，應該生成一個警告或者告警。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
在
postgres數據庫中執行下列查詢：
SELECT * FROM gp_segment_configuration WHERE mode = 'r'; |
當這個查詢返回行時，它表示那些Segment正在被重新同步。如果狀態沒有從'r'變成's'，那么在受影響的Segment的主Segment和鏡像Segment的pg_log文件中檢查錯誤。 |
| 檢查沒有以其最優角色運轉的Segment。如果找到任何Segment，該集群可能不平衡。如果任何行被返回，應該生成一個警告或者告警。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
在
postgres數據庫中執行下列查詢：
SELECT * FROM gp_segment_configuration WHERE preferred_role <> role; |
當Segment沒有運行在其首選角色中時，每台主機上可能不是都有均勻數據量的主Segment，這表示處理是傾斜的。等待一個可能的窗口並且重啟數據庫將Segment帶回到它們的首選角色。 |
| 運行一個分布式查詢來測試它運行在所有Segment上。對每個主Segment都應返回一行。 推薦頻率：每5到10分鍾 重要度： CRITICAL |
在
postgres數據庫中執行下列查詢：
SELECT gp_segment_id, count(*)
FROM gp_dist_random('pg_class')
GROUP BY 1;
|
如果這個查詢失敗，就說明該集群中存在分派到某些Segment的問題。這是一種少見的事件。檢查無法被分派的主機確保沒有硬件或者網絡問題。 |
| 在一個Greenplum數據庫 4.2或者更早的集群上測試Master鏡像的狀態。如果值是"Not Synchronized"，則拋出一個告警或者警告。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
在
postgres數據庫中執行下列查詢：
SELECT summary_state FROM gp_master_mirroring; |
在來自Master和后備Master的pg_log中檢查錯誤。如果沒有意料之外的錯誤並且機器是啟動的，運行gpinitstandby工具將后備Master帶回到線上。在GPDB 4.2及更早的版本上，這要求一次數據庫重啟。 |
| 在Greenplum數據庫上測試Master鏡像的狀態。如果該值不是"STREAMING"，則拋出一個告警或者警告。 推薦頻率：每5到10分鍾 重要度： IMPORTANT |
運行下列
psql命令：
psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;' |
從來自Master和后備Master的pg_log文件中檢查錯誤。如果沒有意料之外的錯誤並且機器是啟動的，運行gpinitstandby工具將后備Master帶回到線上。 |
| 執行一次基本檢查看看Master是否啟動且工作。 推薦頻率：每5到10分鍾 重要度： CRITICAL |
在
postgres數據庫中運行下列查詢：
SELECT count(*) FROM gp_segment_configuration; |
如果這個查詢失敗，則活動Master可能宕機。多嘗試幾次，然后手工檢查活動Master。如果活動Master確實已經宕機，重新引導或者重啟活動Master以確保沒有進程留在活動Master上，然后觸發后備Master的激活。 |
數據庫告警日志監控
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 從系統中檢查FATAL和ERROR日志消息。 推薦頻率：每15分鍾 重要度： WARNING 這項活動和接下來的一項是監控log_alert_history表中消息的兩種方法。只需要設置其中一種即可。 |
在
gpperfmon數據庫中運行下列查詢：
SELECT * FROM log_alert_history
WHERE logseverity in ('FATAL', 'ERROR')
AND logtime > (now() - interval '15 minutes');
|
向DBA發送一個告警讓他（她）分析該告警。可能想要對該查詢增加額外的過濾條件忽略掉興趣度不高的特定消息。 |
| 設置服務器配置參數來發送SNMP 或者 email告警。 推薦頻率：N/A。告警由系統生成。 重要度： WARNING 這項活動和上一項是監控log_alert_history表中消息的兩種方法。只需要設置其中一種即可。 |
啟用服務器配置參數以通過
SNMP 或者 email發送告警：
|
DBA基於告警的性質采取行動。 |
硬件和操作系統監控
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 底層平台檢查需要進行的維護或者硬件問題。 推薦頻率：實時（如果可能），或者每15分鍾 重要度： CRITICAL |
為硬件和OS錯誤設置SNMP或其他系統檢查。 | 如果需要，從Greenplum集群移除一台機器以解決硬件及OS問題，然后把它加回到集群中並且運行gprecoverseg。 |
| 檢查卷上用於Greenplum數據庫數據存儲和OS的磁盤空間使用。 推薦頻率：每5到30分鍾 重要度： CRITICAL |
設置一個磁盤空間檢查。
|
通過移除一些數據或者文件釋放系統上的空間。 |
| 檢查網絡接口上的錯誤或者丟包。 推薦頻率：每小時 重要度： IMPORTANT |
設置一個網絡接口檢查。 | 與網絡和OS團隊一起解決問題。 |
| 檢查RAID錯誤或者RAID性能退化。 推薦頻率：每5分鍾 重要度： CRITICAL |
設置一個RAID檢查。 |
|
| 運行Greenplum的gpcheck工具來測試集群的配置中編寫有當前的推薦。 推薦頻率：在創建集群時或者向集群中增加新機器時 重要度： IMPORTANT |
運行gpcheck。 | 與系統管理團隊一起根據gpcheck工具做出的推薦更新配置。 |
| 檢查足夠的I/O帶寬和I/O傾斜。 推薦頻率：創建集群時或者懷疑有硬件問題時。 |
運行Greenplum的gpcheckperf工具。 |
如果數據傳輸率與下列不相似，則集群可能存在不足：
如果集群上的機器顯示出一種不均勻的性能畫像，與系統管理團隊一起修復有錯誤的機器。 |
目錄監控
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 運行目錄一致性檢查以確保集群中每台主機上的目錄都是一致的並且處於好的狀態。 推薦頻率：每周 重要度： IMPORTANT |
在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -O |
對任何檢測到的問題運行修復腳本。 |
| 運行一個長期的表目錄檢查。 推薦頻率：每月 重要度： CRITICAL |
在一次停機時間，在系統中沒有用戶時，在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -R persistent |
對任何檢測到的問題運行修復腳本。 |
| 檢查沒有相應pg_attribute項的pg_class項。 推薦頻率：每月 重要度： IMPORTANT |
在一次停機時間，在系統中沒有用戶時，在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -R pgclass |
對任何被發現的問題運行修復腳本。 |
| 檢查泄露的臨時方案和丟失的方案定義。 推薦頻率：每月 重要度： IMPORTANT |
在一次停機時間，在系統中沒有用戶時，在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -R namespace |
對任何被發現的問題運行修復腳本。 |
| 檢查隨機分布表上的約束。 推薦頻率：每月 重要度： IMPORTANT |
在一次停機時間，在系統中沒有用戶時，在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -R distribution_policy |
對任何被發現的問題運行修復腳本。 |
| 檢查非存在對象上的依賴。 推薦頻率：每月 重要度： IMPORTANT |
在一次停機時間，在系統中沒有用戶時，在每個數據庫中運行Greenplum的gpcheckcat工具： gpcheckcat -R dependency |
對任何被發現的問題運行修復腳本。 |
數據維護
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 檢查表上缺失的統計信息。 | 在每個數據庫中檢查gp_stats_missing視圖： SELECT * FROM gp_toolkit.gp_stats_missing; |
在缺少統計信息的表上運行ANALYZE。 |
| 檢查數據文件中出現膨脹（死亡空間）且無法用常規VACUUM命令恢復的表。 推薦頻率：每周或每月 重要度： WARNING |
在每個數據庫中檢查gp_bloat_diag視圖： SELECT * FROM gp_toolkit.gp_bloat_diag; |
在沒有用戶訪問該表示執行一個VACUUM FULL語句以移除膨脹並且緊湊數據。 |
數據庫維護
| 活動 | 過程 | 糾正措施 |
|---|---|---|
| 在堆表中標記所占用空間可被重用的已刪除行。 推薦頻率：每日 重要度： CRITICAL |
清理用戶表： VACUUM <table>; |
定期清理被更新的表以防止膨脹。 |
| 更新表統計信息。 推薦頻率：在裝載數據后且在執行查詢前 重要度： CRITICAL |
分析用戶表。用戶可以使用analyzedb管理工具： analyzedb -d <database> -a |
定期分析被更新的表，這樣優化器能產生有效的查詢執行計划。 |
| 備份數據庫數據。 推薦頻率：每日，或者根據備份計划的要求 重要度： CRITICAL |
運行gpcrondump工具並行地創建Master和Segment數據庫的備份。 | 最佳做法是在數據庫必須被恢復時已經有一個當前的備份准備好。 |
| 清理、重新索引以及分析系統目錄以維護一個高效的目錄。 推薦頻率：每周，或者當數據庫對象被頻繁創建和刪除時使用更高的頻率 |
|
優化器從系統表檢索信息來創建查詢計划。如果系統表和索引被允許隨時間膨脹，系統表上的掃描會增加查詢執行時間。在重新索引后運行ANALYZE很重要，因為REINDEX 會讓索引上沒有統計信息。
來自：https://gp-docs-cn.github.io/docs/admin_guide/monitoring/monitoring.html |