国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

OracleGoldenGate告警部署異常引發的數據庫數據同步思考

IT那活兒 / 2767人閱讀
OracleGoldenGate告警部署異常引發的數據庫數據同步思考

點擊上方“IT那活兒”,關注后了解更多精彩內容!!

文章前言

本文通過總結一次由OracleGoldenGate(下文簡稱OGG)監控告警部署問題引發的問題,獲得對于該問題的解決方案和經驗教訓。在此基礎上,做出跟廣泛而深入的思考。在更好的注意告警部署細節的同時,提出借助平臺化、白屏化思想來規避細節的方法,形成簡單的口訣(一要完備測試,二要規范文檔,三要場景平臺化)方便記憶的同時,繼而對該問題繼續進行擴展,簡要論述OGG與ADG聯合架構部署的思路[1]和更多OGG監控模式的思考。

技術背景

OGG是一種基于日志的結構化數據復制軟件。OGG能夠實現大量交易數據的實時捕捉、變換和投遞,實現源數據庫與目標數據庫的數據同步,保持亞秒級的數據延遲。一個經典的OGG雙向同步架構如圖一所示:
圖一 OGG雙向同步架構
OGG因為其精密的特性,需要實時監控其運行狀態,因此對于一套OGG系統,部署一套監控告警,以獲取OGG延時信息自動發現并能夠發送對應的告警信息變得尤為關鍵。

問題描述

1. 問題產生復盤

問題發生于2021年12月28日9:00
問題發現于2021年12月29日9:00
問題發生背景:因計費ACCT庫于2021年12月28日凌晨由主機A遷移至主機B,故需要在割接完成后,在新庫(主機B)上部署OGG告警定時任務。但當晚在部署任務時操作出現若干失誤,導致告警腳本并未即可正常工作。
問題發生負面影響:割接完成后當天,Oracle數據庫經歷了兩次重啟。重啟時OGG抽取進程Abended,而此時并未產生告警,直到次日上午手動進入主機查看后才發現進程異常。但此時抽取進程啟動所需歸檔已經被自動清理抽取進程無法啟動
圖二 抽取進程啟動報錯信息

2. 產生問題原因

2.1 MGR進程參數設置問題:
因為此次割接時,OGG的MGR并非手動創建的,因此沒有對它的參數進行檢查,導致進程異常后,MGR進程不會正常拉起Abended進程。
2.2 告警腳本配置問題:
告警腳本的定時任務里有兩條,分別用于監控進程查詢腳本是否被屏蔽,以及監控進程并發送短信告警。在當晚測試時,僅對第一條定時任務的有效性做了檢查,并未檢查第二條定時任務的執行效果。直到次日進行進程核查時,才發現告警腳本配置問題。檢查告警腳本的第二條定時任務后,發現兩條報錯:
  • 發送告警信息的定時任務無法執行,報錯輸出文件目錄不存在。

  • 發送告警信息的定時任務(send_JF.sh)無法執行,報錯系統JF不存在。

2.3 解決方案

2.3.1 配置MGR進程參數并重啟MGR進程:
重新配置MGR進程參數,添加自動拉起進程配置。
圖三 重新配置MGR進程參數
2.3.2 重新配置告警腳本:
對于第一個問題「報錯輸出文件目錄不存在」,發現是輸出文件目錄未修改,修改目錄后出現輸出文件。
對于第二個問題「報錯系統JF不存在」,發現是ogg_send.json配置文件里系統名未修改。修改系統名后成功收到告警短信。
圖四 修改目錄
圖五 修改系統名
2.3.3 手動恢復歸檔后重新拉起進程:
查詢當前保留的的歸檔文件目錄,發現最近的兩個節點最近的歸檔文件在Seq.176左右,而進程所需歸檔文件需要恢復到Seq.134左右。

2.4 經驗教訓

這次的進程異常問題,只要在任意一步里處理好,都不會導致最終需要重新恢復歸檔(如果MGR配好了參數,出現進程Abended就能夠自動拉起;如果配好了告警,出現進程Abended就能夠立刻得到消息)
但這樣的失誤也有一個“好處”,就是同時發現了兩個問題。而如果其中一個問題不犯錯,那么就發現不了另一個問題(如果MGR配好了參數,出現進程Abended就能夠自動拉起,那么就不會發現告警腳本沒有配置好)
因此,對于其中導致錯誤最關鍵的兩步做出如下總結:
  • 檢查MGR進程參數:不論MGR進程是否為手動創建,都要仔細檢查其參數配置。推廣到更一般的情況,就是在進行操作時,對所有與該操作有關的信息進行核查。

  • 告警腳本完整測試:部署告警腳本的時候,需要對所有涉及的腳本進行測試。推廣到更一般的情況,就是在進行操作時,對所有可能觸發該操作的情況進行校驗。

引發思考

1. 告警部署中的細節

除了在上文中提到的忽略的細節,部署監控告警腳本的細節并不少。
在本案例中,一個規范的部署過程包括如下步驟:
step1 從FTP服務器的ogg目錄下載對應文件(需要下載的文件參考其他正常運行ogg的主機)。
step2 將對應文件根據定時任務參數放到對應的文件目錄。
step3 從ogg進程參數里獲得ogg在數據庫中的用戶名和密碼,修改ora文件里的內容。
step4 從其他正常運行ogg的主機獲取新的send_XX.sh文件和ogg_send.json文件覆蓋從FTP服務器上下載的文件。并且修改ogg_send.json中的system_name為send_XX.sh中下劃線的后綴XX。
step5 使用測試進程來盡可能完備的測試告警是否正常(一測監控告警腳本的腳本是否正常,二測告警腳本是否正常,三測定時任務是否正常)。
對于這些細節和錯誤處理的過程,需要形成規范化的流程文檔,以盡可能防范問題再次發生。

2. 規避細節以永久性規避失誤

注意這些細節,并對可能犯錯的細節做總結的目的,并不在于在每次實施中都要檢查這些細節。而是將復雜的細節盡可能地隱去,讓這個操作的難度、門檻越來越低的同時,操作發生問題的可能性自然也會越來越低
如今,業內越來越多的開始采用平臺化、白屏化的方式進行各類復雜操作的處理(如下圖)。OGG的監控告警部署同樣可以使用這樣的模式,讓操作更加方便的同時,更讓操作的門檻變得很低。不需要明白操作內部的原理,只需要在平臺上完成簡單的參數設置,就能夠達到想要的目的。
圖六 白屏化操作示例

3. 口訣式概括

上述過程總結,可以概括為如下口訣:
告警部署,一要完備測試,二要規范文檔,三要場景平臺化。
值得一提的是,這個口訣可以推廣到更多的場景里。

更多拓展

1. OGG與ADG聯合架構部署

OGG只能提供準實時數據同步。另一種情況是,邏輯復制受到業務邏輯本身的限制,如果有大量的大型事務,就會發生擁塞,這通常是讀寫密集型業務不需要的,Oracle11g的新特性ActiveDataGuard(以下簡稱ADG)很好地解決了這個問題。ADG或者簡稱為DG可以打開的數據庫保護,允許在應用來自主庫的日志時以只讀模式打開數據庫。這意味著備用數據庫不僅可以與主數據庫同步,還可以提供實時查詢來滿足數據庫讀寫分離的需求。一個經典的ADG架構如圖七所示。
圖七 經典ADG架構
OGG和ADG可以聯合部署,一個經典的基于OGG和ADG的災難備用數據庫讀寫分離架構如圖八所示。它具有以下優點:
(1)采用OGG雙向復制技術,有效保證數據一致性;
(2)備用數據庫節點靈活、可擴展。它們可以在線添加或刪除,并且可以線性擴展而不影響生產系統。
(3)能夠真正實現實時查詢,非大交易造成同步塊,性能保證。
(4)高可用性,節點停機時間不會影響數據庫的可用性。
圖八 使用OGG和ADG聯合的災難備用數據庫的讀寫分離架構

2. 更多OGG監控模式的思考

在之前的問題里,僅僅思考了一套OGG系統的監控告警部署情況,也僅僅關注了進程運行狀態與延時信息。但在實際的場景中(例如上面提到的多個OGG和ADG聯合的災難備用數據庫的讀寫分離架構),維護人員需要看到的就不只是進程信息,它們還需要看到整體架構圖等信息。
圖九 OGG Monitor效果圖
圖十 OGG Director監控創建流程
圖十一 使用Zabbix3.2監控OGG延時效果圖
在這方面,能看到業內做過的很多嘗試。有官方提供的OGG Monitor的解決方案(如圖九所示),也有使用OGG Director監控的解決方案(如圖十所示),還有使用Zabbix3.2監控OGG延時的解決方案(如圖十一所示)。這些解決方案在部署成本上、使用面上、適用系統特征上各有優劣,需要使用者靈活選擇。

總   結

數據庫同步技術的發展日新月異,在Oracle規模本身更加龐大的同時,其數據同步組件本身的復雜性也在日記增加。近年來,有工作專注于對其架構的調整[1],也有工作專注于對其性能和公共數據連接部分的優化,有工作在分析原有集群技術的基礎上,提出了一種新的數據庫集群無共享磁盤結構[2]。它們在解決數據庫備份、數據容災和負載均衡問題上都發揮著作用。在此情境下,如何更好的監控整個OGG的狀態,成了一個愈發值得關注的問題,而自動化也將成為進一步研究的重要方向。
本文在論述具體問題的過程中,存在一定程度的特殊性。它所提供的解決方案并不一定在所有情境下適用。但在本文中,更希望的是借著對這個問題的復盤,闡述對這個問題的處理思路和繼而闡發的思考和拓展,從而能夠激發讀者思維深度和廣度

參考文獻:

[1] J. Hu, B. Yang, R. Yan, Q. Wang and K. Lin, "Disaster Preparedness Backend Database to Read and Write Separation Technology Research," 2020 2nd International Conference on Computer Communication and the Internet (ICCCI), 2020, pp. 88-92, doi: 10.1109/ICCCI49374.2020.9145978.
[2] Y. Xiao and Q. Gong, "Universal Database Cluster Solution -- Based on Goldengate," 2011 International Conference on Computational and Information Sciences, 2011, pp. 254-256, doi: 10.1109/ICCIS.2011.308.






本 文 原 創 來 源:IT那活兒微信公眾號(上海新炬王翦團隊)


文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/129671.html

相關文章

  • AIOps在攜程踐行

    摘要:隨著人工智能時代的到來,攜程生產環境運維進入了新的運維時代。本文選取了幾種典型的運維場景對在攜程的踐行展開了介紹,首先讓我們從概念認識下。針對應用異常指標檢測這種場景,抽取一定的樣本統計,在基于專家經驗標注下的準確率可達到以上,召回率接近。 作者簡介徐新龍,攜程技術保障中心應用管理團隊高級工程師,負責多個AIOps項目的設計與研發。信號處理專業碩士畢業,對人工智能、機器學習、神經網絡及數學有...

    MingjunYang 評論0 收藏0
  • 雷神 Thor —— TiDB 自動化運維平臺

    摘要:相當于分布式數據庫的大腦,一方面負責收集和維護數據在各個節點的分布情況,另一方面承擔調度器的角色,根據數據分布狀況以及各個存儲節點的負載來采取合適的調度策略,維持整個系統的平衡與穩定。原文鏈接雷神自動化運維平臺 作者:瞿鍇,同程藝龍資深 DBA 背景介紹 隨著互聯網的飛速發展,業務量可能在短短的時間內爆發式地增長,對應的數據量可能快速地從幾百 GB 漲到幾百個 TB,傳統的單機數據庫提...

    RayKr 評論0 收藏0
  • 如何讓運維指標變得更有價值?

    摘要:為了掌握你的告警事件響應時間,在你已經開始處理告警時,強烈建議及時響應認領,例如通過移動端微信頁面移動等方式及時認領。這一點國外做的很棒,在短信電話移動都可以很容易確認認領在微信端可以認領和關閉。 這是《運維不容錯過的4個關鍵指標》的姐妹篇,上篇文章介紹了優秀運維團隊需要關注的4個關鍵指標,我們分享了平均恢復時間 MTTR、平均響應時間 MTTA 等概念。這篇是介紹一些實踐方法,更好的...

    suxier 評論0 收藏0
  • vivo統一告警平臺設計與實踐

    摘要:告警當一個問題通過告警系統將消息以短信電話郵件等方式告知給用戶時,我們稱之為一條告警。圖統一告警系統結構圖告警收斂對于告警平臺每天會產生數以萬計的告警,這些告警對于運維或開發人員都需要去分析甄別優先級并處理故障。 一、背景一套監控系統檢測和告警是密不可分的,檢測用來發現異常,告警用來將問題信息發送給相應的人。v...

    Rocko 評論0 收藏0

發表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<