亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

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

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

點(diǎn)擊上方“IT那活兒”,關(guān)注后了解更多精彩內(nèi)容??!

文章前言

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

技術(shù)背景

OGG是一種基于日志的結(jié)構(gòu)化數(shù)據(jù)復(fù)制軟件。OGG能夠?qū)崿F(xiàn)大量交易數(shù)據(jù)的實(shí)時捕捉、變換和投遞,實(shí)現(xiàn)源數(shù)據(jù)庫與目標(biāo)數(shù)據(jù)庫的數(shù)據(jù)同步,保持亞秒級的數(shù)據(jù)延遲。一個經(jīng)典的OGG雙向同步架構(gòu)如圖一所示:
圖一 OGG雙向同步架構(gòu)
OGG因?yàn)槠渚艿奶匦?,需要?shí)時監(jiān)控其運(yùn)行狀態(tài),因此對于一套OGG系統(tǒng),部署一套監(jiān)控告警,以獲取OGG延時信息、自動發(fā)現(xiàn)并能夠發(fā)送對應(yīng)的告警信息變得尤為關(guān)鍵。

問題描述

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

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

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

2.1 MGR進(jìn)程參數(shù)設(shè)置問題:
因?yàn)榇舜胃罱訒r,OGG的MGR并非手動創(chuàng)建的,因此沒有對它的參數(shù)進(jìn)行檢查,導(dǎo)致進(jìn)程異常后,MGR進(jìn)程不會正常拉起Abended進(jìn)程。
2.2 告警腳本配置問題:
告警腳本的定時任務(wù)里有兩條,分別用于監(jiān)控進(jìn)程查詢腳本是否被屏蔽,以及監(jiān)控進(jìn)程并發(fā)送短信告警。在當(dāng)晚測試時,僅對第一條定時任務(wù)的有效性做了檢查,并未檢查第二條定時任務(wù)的執(zhí)行效果。直到次日進(jìn)行進(jìn)程核查時,才發(fā)現(xiàn)告警腳本配置問題。檢查告警腳本的第二條定時任務(wù)后,發(fā)現(xiàn)兩條報錯:
  • 發(fā)送告警信息的定時任務(wù)無法執(zhí)行,報錯輸出文件目錄不存在。

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

2.3 解決方案

2.3.1 配置MGR進(jìn)程參數(shù)并重啟MGR進(jìn)程:
重新配置MGR進(jìn)程參數(shù),添加自動拉起進(jìn)程配置。
圖三 重新配置MGR進(jìn)程參數(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ù)歸檔后重新拉起進(jìn)程:
查詢當(dāng)前保留的的歸檔文件目錄,發(fā)現(xiàn)最近的兩個節(jié)點(diǎn)最近的歸檔文件在Seq.176左右,而進(jìn)程所需歸檔文件需要恢復(fù)到Seq.134左右。

2.4 經(jīng)驗(yàn)教訓(xùn)

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

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

引發(fā)思考

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

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

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

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

3. 口訣式概括

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

更多拓展

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

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

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

在之前的問題里,僅僅思考了一套OGG系統(tǒng)的監(jiān)控告警部署情況,也僅僅關(guān)注了進(jìn)程運(yùn)行狀態(tài)與延時信息。但在實(shí)際的場景中(例如上面提到的多個OGG和ADG聯(lián)合的災(zāi)難備用數(shù)據(jù)庫的讀寫分離架構(gòu)),維護(hù)人員需要看到的就不只是進(jìn)程信息,它們還需要看到整體架構(gòu)圖等信息。
圖九 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)劣,需要使用者靈活選擇。

總   結(jié)

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

參考文獻(xiàn):

[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那活兒微信公眾號(上海新炬王翦團(tuán)隊(duì))


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

轉(zhuǎn)載請注明本文地址:http://www.ezyhdfw.cn/yun/129671.html

相關(guān)文章

  • AIOps在攜程踐行

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

    MingjunYang 評論0 收藏0
  • 雷神 Thor —— TiDB 自動化運(yùn)維平臺

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

    RayKr 評論0 收藏0
  • 如何讓運(yùn)維指標(biāo)變得更有價值?

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

    suxier 評論0 收藏0
  • vivo統(tǒng)一告警平臺設(shè)計(jì)與實(shí)踐

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

    Rocko 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

|高級講師

TA的文章

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