源端RAC数据库删除实例操作时GoldenGate的运维流程
文章背景
周六下午突然接到一個頗為頭疼的任務——盡快為某客戶提供一個?GoldenGate?操作方案，大體背景如下：
客戶的生產環境是?Oracle 11GR2?的三節點的?RAC?，上面部署了兩套?GoldenGate軟件，一套抽取在線日志?+?歸檔文件、一套為?ALO?（?Archived Log Only?，即只讀歸檔）模式，由于數據庫方面的原因，需要盡快做刪除其中一個實例的操作，由于上面部署了?GoldenGate?軟件，需要給出具體的運維流程，以保證刪除實例的操作不影響GoldenGate?的數據同步。
筆者沒有接觸過這種場景，為了保持真實性，只好找三節點的環境做測試了，最終在幾位同事的熱心協助下，經過一天多的奮斗，終于在周一凌晨完成模擬環境下的測試并輸出具體方案。
下文中，筆者將以?Q&A?的方式說明操作的關鍵點。
?
Q1:?不進行人工干預的情況下，源端刪除實例的操作對GoldenGate?有何影響：
A1:
???????源端刪除實例的操作主要影響?GoldenGate?抽取進程的運行。
針對?ALO?模式的?GoldenGate?抽取進程，由于?GoldenGate?需要獲取各個實例的歸檔信息進行排序，因此不能缺少任一個節點的歸檔文件。刪除實例的操作將使得GoldenGate?抽取進程因缺少被刪除節點歸檔文件而無法正常工作，最終導致同步中斷。注意，此處無法正常工作的表現形式不是顯式的?ERROR?信息或者?WARNNING?信息，而是源端數據庫發生變化，但隊列文件無任何變更，且?current checkpoint?一直不變。
針對抽取在線日志?+?歸檔文件方式的?GoldenGate?抽取進程，由于刪除實例的操作會觸發數據庫側在線日志組被刪除的操作，?GoldenGate?找不到相應日志組的時候會出現報錯，筆者在虛擬機中遇到的錯誤如下：
?????除此之外，還有一種特殊的情況，那就是?GoldenGate?仍然為抽取在線日志?+?歸檔日志的模式，但由于?GoldenGate?軟件的?BUG?，在被刪除實例停止且尚未執行刪除操作的時候，?GoldenGate?就已經停止工作（狀態?RUNNING?，隊列文件無任何變更，且?current checkpoint?一直不變）。這兩天里面筆者在?Oracle DATABASE 11.2.0.1?的2?節點?RAC?環境以及?Oracle Database 11.2.0.2?的?3?節點?RAC?環境下分別作了測試，僅在?Oracle Database 11.2.0.1?的?2?節點?RAC?環境遇到這種情況，此環境還有一個異常就是當一個節點空閑另一個節點上完全沒有事務的時候，抽取進程直到另外一個節點有事務提交的時候才成功抽取。
?
Q2: GoldenGate?該如何配合源端執行刪除實例的操作？
A2?：
由于具體方案過于瑣碎，筆者這里先說明大致的思路，涉及的細節下文會另外描述。
筆者分三個階段進行處理。
第一階段為“前期準備階段”，此階段在刪除實例的工程實施前進行，主要工作包括參數測試以及調整、長事務處理。
第二階段為“停止待刪除實例階段”，此階段?Oracle DBA?將進行停止待刪除實例的操作，?GoldenGate?的重點工作為保障此實例后，抽取進程仍然可以正常工作，抽取變化數據。這樣做是為了讓刪除實例階段，?GoldenGate?抽取進程的?current checkpoint?能到達甚至超過實例被刪除的時間點。
第三階段為“刪除實例階段”，此階段?Oracle GoldenGate?將執行刪除實例的操作，GoldenGate?的重點工作為確保隊列文件延續性的前提下，重建抽取進程，使得GoldenGate?抽取進程能在調整后的環境下正常工作。
?
在完成整個文檔后，筆者給自己提了一個問題：“刪除實例當天，?Oracle DBA?一氣呵成地執行停止實例、刪除實例操作，之后再作?GoldenGate?的調整，這樣做溝通成本會降低，但可不可行呢？”
從剛開始規劃方案到現在，筆者一直擔心出現下述狀況，源端數據庫在三個節點的RAC?環境下，而?GoldenGate?卻僅以兩個節點方式去處理，這種做法必然造成抽取進程的數據丟失。那么，?DBA?“一氣呵成”的做法能否避免這種狀況呢？
至少從筆者測試的情況來看，停止實例后，就疑似因為?BUG?而?current checkpoint停滯不前，無法到達停止實例的時間點。測試環境尚且如此，誰能保證生成環境操作當天不遇到意外呢？于是我最終肯定了之前的想法，分兩個階段處理停止實例和刪除實例。
Q3: GoldenGate?哪些技術細節對配合源端執行刪除實例的操作存在影響？
A3:
筆者以列表形式總結如下：
| 技術細節 | 影響點 |
| 由于?GoldenGate?的?BUG?，抽取進程的?Bound Recovery?功能將無法使用 | 1）?需要進行長事務清理，具體處理原則需要事前拍板； 2）?需要保留足夠的歸檔文件； 3）?調整抽取進程前需要檢查?recovery checkpoint?。 |
| ALO?模式的?GoldenGate?需要各個節點歸檔日志才能繼續工作 | 1）?必要時需要進行手工切換在線日志并傳輸的操作，以觸發?ALO?模式GoldenGate?抽取進程工作 2）?如需在某個實例停止的情況下繼續工作，則需要使用?GoldenGate?參數THREADOPTIONS PROCESSTHREADS?。 |
| THREADOPTIONS PROCESSTHREADS?為?undocumented參數 | 請在項目準備階段測試此參數是否可行。 |
| 抽取在線日志?+?歸檔日志的模式下可能存在?BUG?，導致停止某個實例的情況下?current checkpoint?停滯不前 | 必要時采用?GoldenGate?參數THREADOPTIONS PROCESSTHREADS?。 |
| 正常情況下，抽取在線日志?+?歸檔日志的模式，刪除實例的操作會觸發數據庫相應在線日志組被刪除，進而導致GoldenGate?進程?ABEND | 這是正常現象，僅需要按流程重建抽取進程即可 |
| 重建?GoldenGate?抽取進程涉及各實例的?current checkpoint?和?recovery checkpoint?，前者必須先修改，此外還涉及隊列文件的?current checkpoint | 1）?重建的過程務必注意操作的順序 2）?重建完畢后務必對各個?checkpoint作檢查，確保結果一致 |
| GoldenGate?所識別的實例順序不一定等于數據庫的實例順序 | 1）?THREADOPTIONS PROCESSTHREADS EXCEPT?后跟的實例好為數據庫實例 2）?ALTER?操作后跟的?THREAD?參數執行的是?GoldenGate?識別的實例順序 3）?啟用此參數后，安全起見，應該利用自定義的表作一次檢查 |
?
Q4: GoldenGate?如何保障某個實例被停止后抽取進程正常工作？
A4:
???????通常情況下，被停止的實例并非?GoldenGate?所部署的實例的話，僅會影響?ALO模式的?GoldenGate?抽取進程，導致此進程因沒有歸檔文件而?current checkpoint?停滯不前。
解決方案為使用?THREADOPTIONS PROCESSTHREADS?參數，具體例子如下：
其中的數字為數據庫的實例號。
???????筆者在測試中遇到一個異常，由于之前設定的歸檔路徑重疊，而?GoldenGate?因實例已經終止無法獲取?log_archive_format?參數設置，而無法啟動，最終解決方法為在參數文件中補充相應配置，具體例子如下：
???????對于抽取在線日志?+?歸檔日志的?GoldenGate?抽取進程，如果遇到?BUG?而出現current checkpoint?停滯不前的情況，也可以參照?ALO?模式的處理方式，添加THREADOPTIONS PROCESSTHREADS?參數。
?
Q5:?哪些手段能進一步保障整數據庫刪除實例相應的GoldenGate?配合流程？
A5:
為減少外界的干擾，可考慮通過下述手段進一步判斷
1）?暫停管理進程的自動重啟策略
2）?暫停管理進程的隊列文件清理策略
刪除抽取進程后，原有的隊列文件可能會被管理進程誤刪，為避免這種情況，可暫停管理進程相應策略。
3）?抽取進程啟用?REPORTCOUNT?參數，監控記錄變更情況
參考配置如下：
???????此參數可以讓?GoldenGate?進程每分鐘報告報告變更的記錄情況，輸出結果例子如下：
???????此值可以與平時的情況相比，協助分析是否出現異常。
4）?配置?GoldenGate?監控表并捕獲變更情況，協助分析進程工作情況
在各實例分別創建一個數據庫表，以實例?1?為例，表名?goldengate.node1?，自動腳本每個?5?秒鐘往這個表插入一條數據。
將新增的幾個表加入?GoldenGate?抽取進程策略，并以獨立的隊列文件存儲。每當關鍵操作時，通過對?GoldenGate STATS?信息的監控判斷?GoldenGate?有沒有抽取相應實例的變更信息。
5）?抽取進程調整前后暫停投遞進程工作，避免抽取進程異常改造誤修改數據
在每次?GoldenGate?抽取進程調整之前，在停止抽取進程后，確認投遞進程已經追平的前提下，暫停投遞進程工作。
待確認抽取進程已經正常工作后，才恢復投遞進程工作。
假如抽取進程出現異常，且抽取了錯誤的數據，則通過修改投遞進程時間點的方式跳過相應的記錄避免錯誤的數據入庫。
?
Q6:?重建抽取進程期間?GoldenGate?如何準確修改各個checkpoint?
A6:
步驟?1?）獲取現有隊列文件的?checkpoint?信息并清理舊進程
??????Oracle GoldenGate?重建抽取進程前，需要通過?info xxx,showch?的命令獲取當前的?checkpoint?信息，此步驟非常關鍵，務必執行準確。
???在獲取抽取進程信息后，就可以進行刪除舊的抽取進程，開始重建工作。
步驟?2?）添加新的抽取進程
添加進程的語句與以往的創建方式是類似的，但?threads?需要相應減?1?，例子如下：
步驟?3?）為新的抽取進程添加隊列文件
添加進程后，需要配置相應的隊列文件，與以往創建方式不同，這里需要加入原有隊列文件的?current checkpoint?信息。例子如下：
???????從之前的?info xxx,showch?中獲取隊列文件?current checkpoint?信息如下：
???????相應增加隊列文件命令如下：
步驟?4?）確認?GoldenGate?識別實例順序信息
接下來需要確認?GoldenGate?識別的實例順序是否與數據庫配置一致，操作例子如下：
????得到的關鍵信息如下：
???????上述信息僅需要留意順序即可，其中錯誤的“?THREAD #:2?”信息將在實例啟動后自動調整，無需特殊處理。除此之外，我們還可以通過下述語句獲取實例順序信息：
????如果出現?GoldenGate?識別順序與數據庫實際情況不一樣，那么接下來的?ALTER EXT?命令就要替換相應的?THREAD?參數。
步驟?5?）修改抽取進程的?current checkpoint?信息。
接下來的操作為修改抽取進程的?current checkpoint?，由于此操作會觸發?recovery checkpoint?信息變更，因此必須先于?recovery checkpoint?調整。
例如從舊的?checkpoint?信息得到關鍵信息如下：
???????相應的執行語句例子如下：
步驟?6?）修改抽取進程的?recovery checkpoint?信息。
???????修改抽取進程?recovery checkpoint?信息的操作并非?Oracle GoldenGate?所Support?的操作，因此在執行期間，?GoldenGate?會要求用戶確認，此處按?Y?讓流程繼續即可。
例如從舊的?checkpoint?信息得到關鍵信息如下：
???????相應執行的語句例子如下：
步驟?7?）檢查?GoldenGate?抽取進程時間點信息
???????此步驟為最終的檢查項，目的在于驗證抽取進程時間點信息是否一致。
?
總結
以上是生活随笔為你收集整理的源端RAC数据库删除实例操作时GoldenGate的运维流程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Slave: received end
- 下一篇： 加快mysql导入、导出速度