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

資訊專欄INFORMATION COLUMN

OracleGoldenGate告警部署異常引發(fā)的數(shù)據(jù)庫數(shù)據(jù)同步思考

IT那活兒 / 2757人閱讀
OracleGoldenGate告警部署異常引發(fā)的數(shù)據(jù)庫數(shù)據(jù)同步思考

點擊上方“IT那活兒”，關注后了解更多精彩內(nèi)容！！

文章前言

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

技術背景

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

問題描述

1. 問題產(chǎn)生復盤

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

2. 產(chǎn)生問題原因

2.1 MGR進程參數(shù)設置問題：
因為此次割接時，OGG的MGR并非手動創(chuàng)建的，因此沒有對它的參數(shù)進行檢查，導致進程異常后，MGR進程不會正常拉起Abended進程。
2.2 告警腳本配置問題：
告警腳本的定時任務里有兩條，分別用于監(jiān)控進程查詢腳本是否被屏蔽，以及監(jiān)控進程并發(fā)送短信告警。在當晚測試時，僅對第一條定時任務的有效性做了檢查，并未檢查第二條定時任務的執(zhí)行效果。直到次日進行進程核查時，才發(fā)現(xiàn)告警腳本配置問題。檢查告警腳本的第二條定時任務后，發(fā)現(xiàn)兩條報錯：

  • 發(fā)送告警信息的定時任務無法執(zhí)行，報錯輸出文件目錄不存在。

  • 發(fā)送告警信息的定時任務（send_JF.sh）無法執(zhí)行，報錯系統(tǒng)JF不存在。

2.3 解決方案

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

2.4 經(jīng)驗教訓

這次的進程異常問題，只要在任意一步里處理好，都不會導致最終需要重新恢復歸檔。（如果MGR配好了參數(shù)，出現(xiàn)進程Abended就能夠自動拉起；如果配好了告警，出現(xiàn)進程Abended就能夠立刻得到消息）
但這樣的失誤也有一個“好處”，就是同時發(fā)現(xiàn)了兩個問題。而如果其中一個問題不犯錯，那么就發(fā)現(xiàn)不了另一個問題。（如果MGR配好了參數(shù)，出現(xiàn)進程Abended就能夠自動拉起，那么就不會發(fā)現(xiàn)告警腳本沒有配置好）
因此，對于其中導致錯誤最關鍵的兩步做出如下總結：

  • 檢查MGR進程參數(shù)：不論MGR進程是否為手動創(chuàng)建，都要仔細檢查其參數(shù)配置。推廣到更一般的情況，就是在進行操作時，對所有與該操作有關的信息進行核查。

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

引發(fā)思考

1. 告警部署中的細節(jié)

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

2. 規(guī)避細節(jié)以永久性規(guī)避失誤

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

3. 口訣式概括

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

更多拓展

1. OGG與ADG聯(lián)合架構部署

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

2. 更多OGG監(jiān)控模式的思考

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

總   結

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

參考文獻：

[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.






本 文 原 創(chuàng) 來 源：IT那活兒微信公眾號（上海新炬王翦團隊）


文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

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

相關文章

  • AIOps在攜程的踐行

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

    MingjunYang 評論0 收藏0

  • 雷神 Thor —— TiDB 自動化運維平臺

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

    RayKr 評論0 收藏0

  • 如何讓運維指標變得更有價值？

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

    suxier 評論0 收藏0

  • vivo統(tǒng)一告警平臺設計與實踐

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

    Rocko 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

男|高級講師

TA的文章

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