內存數(shù)據(jù)庫遷移方法改進研究

文/李璋琪

1 引言

TimesTen內存數(shù)據(jù)庫是一個針對內存進行了優(yōu)化的關系數(shù)據(jù)庫，它為應用程序提供了當今實時企業(yè)和行業(yè)所需的即時響應性和非常高的吞吐量。因此，常被用于業(yè)務響應及時性要求非常高的場景，例如通信業(yè)務中的實時計費系統(tǒng)。Timesten數(shù)據(jù)庫一般采用兩節(jié)點的主-備機架構來保證內存庫的高可用性，主節(jié)點負責處理業(yè)務讀寫，備節(jié)點接收主節(jié)點傳遞過來的日志，保持備用數(shù)據(jù)庫與主庫數(shù)據(jù)一致。

在系統(tǒng)運維過程中，當需要進行內存數(shù)據(jù)庫底層平臺進行主機更換、存儲設備調整等操作時，必須將內存數(shù)據(jù)庫從原有平臺遷移至新的硬件平臺。目前的遷移方法多采用搭建內存數(shù)據(jù)庫主備復制關系，之后進行切換并激活備用數(shù)據(jù)庫的方式，該方式雖然在速度上優(yōu)于邏輯數(shù)據(jù)導出、導入，但仍難于滿足業(yè)務系統(tǒng)的高實時性要求。

因此，本文在原有遷移方式的基礎上，從原理、速度、風險等方面進行評估，提出通過增加額外備用數(shù)據(jù)庫進行中轉的方式，逐步優(yōu)化與改進，提高遷移速度，降低遷移風險，也為其他類別內存數(shù)據(jù)庫系統(tǒng)的遷移工作提供思路、建議與參考。

圖1：主-備-備方式（不排除Cache Group復制）

圖2：主-備-備方式（排除Cache Group復制）

2 現(xiàn)有方案分析

針對內存數(shù)據(jù)庫的遷移需求，可采用數(shù)據(jù)導出、導入，或新建主-備數(shù)據(jù)庫兩種方式。但基于ttMigrate的數(shù)據(jù)導出、導入方式需要在整個遷移過程期間中斷業(yè)務，且數(shù)據(jù)入庫時以數(shù)據(jù)表為單位，尤其在數(shù)據(jù)導入及重建索引、Cache Group階段所需時間較長，中斷業(yè)務時長約在3-4小時，因此在大規(guī)模的生產環(huán)境中應用較少，最多的方法為新建主-備庫方式。

所謂新建主-備庫方式，即在數(shù)據(jù)庫遷移工程實施過程中，停止原有Timesten內存數(shù)據(jù)庫上連接的業(yè)務，并以原有Timesten內存數(shù)據(jù)庫作為主庫，在新主機上新建一套Timesten內存數(shù)據(jù)庫作為備庫。待完成主備數(shù)據(jù)同步后，切斷該主備同步關系，將新機器上面的備庫切換為主庫使用，完成主機設備更換過程。該方案為目前最常用的方案，但所有操作均需在工程實施過程中停止Timesten內存數(shù)據(jù)庫對外服務。其中，新建主備復制關系耗時需1小時以上，統(tǒng)計信息收集半小時以上，遷移過程產生的影響時長接近2小時。

無論采用現(xiàn)有的何種方式，均需要在工程中較長時間中斷Timesten內存數(shù)據(jù)庫對外服務，在諸如實時計費等電信級別業(yè)務實踐中，均無法有效滿足業(yè)務連續(xù)性要求。因此，有必要找到一種遷移時間短，且風險可控的遷移手段。

3 改進思路與方案

從現(xiàn)有分析中可知，影響遷移時長的環(huán)節(jié)主要有：數(shù)據(jù)導入、重建索引、重建Cache Group，以及新建主備復制關系等過程。因此，縮短遷移時間也應從上述關鍵環(huán)節(jié)入手。

Cache Group是TimesTen內存數(shù)據(jù)庫的一個重要組件，對于現(xiàn)有應用數(shù)據(jù)存放在Oracle Database（或簡稱“物理庫”）中的場景，可通過Timesten內存數(shù)據(jù)庫的Cache Group組件從Oracle物理數(shù)據(jù)庫中按照一定時間間隔將數(shù)據(jù)庫刷新到內存數(shù)據(jù)庫中，實現(xiàn)Oracle物理庫和Timesten內存數(shù)據(jù)庫之間數(shù)據(jù)同步。

在實踐過程中，充分利用高可用架構及備用數(shù)據(jù)庫特點，結合Cache Group組件的刷新方法，采用新建第二套備庫，分別形成兩種主-備-備三臺主機同時在線的過渡架構，并對效果進行了驗證。

3.1 主-備-備方式（不排除Cache Group復制）

在原有的主-備架構內存數(shù)據(jù)庫基礎上，在新增的主機上建立第二套備庫，添加到原有主-備架構的內存數(shù)據(jù)庫集群中，形成主-備-備架構。第二套備庫采用默認的搭建方式（不排除Cache Group），即主備復制策略中包含了針對Cache Group的復制，且第二個備庫（subscriber）是read-only狀態(tài)，所以新增加的備庫上Cache Group表將變?yōu)閷嶓w表（Timesten內部機制決定），必須在工程實施時間窗口內，刪除該實體表并重建為Cache Group。

該方案與現(xiàn)有方案比較，在工程實施時間窗口內減少了數(shù)據(jù)導入、重建索引，以及新建主備復制關系等操作，停機時間有所下降，但仍然必須包含重建Cache Group的操作，尤其在內存庫Cache Group較大的情況下，重建耗時較長，經(jīng)實際測試，100G大小的內存數(shù)據(jù)庫遷移過程耗時約40分鐘，仍不能夠很好地滿足業(yè)務連續(xù)性需求。

方案的技術架構如圖1所示。

3.2 主-備-備方式（排除Cache Group復制）

分析第一次改進方案可知，該方案在搭建第二套備庫時采用了默認方法，重建Cache Group的過程消耗了大量時間。在此基礎上進一步優(yōu)化，通過研究Timesten復制機制，改進了第二套備庫CacheGroup的刷新方法，形成了主-備-備方式（排除Cache Group復制）的方案，方案的技術架構如圖2所示。

可以看到，本方案在新主機（目標服務器）上面搭建了第二套備庫，并且與原有的主庫保持數(shù)據(jù)同步，所以在工程實施過程中無需對位于新主機上的內存數(shù)據(jù)庫進行操作，只需要停止原有的內存數(shù)據(jù)庫，并將應用程序重新連接到新的內存數(shù)據(jù)庫即可，不需要停機時間，對業(yè)務的影響非常小。

方案主要步驟如表1所示。

方案具體實現(xiàn)方式詳細闡述如表2所示。

3.3 改進點與效果分析

本章所述的兩種“主-備-備”架構方案均無需在工程實施時間窗口內進行數(shù)據(jù)導入、重建索引，以及新建主備復制關系等操作。3.2節(jié)所述的“排除Cache Group復制”方案更進一步，與3.1節(jié)所述的“不排除Cache Group復制”方案比較，采用了排除復制策略的方式，也就是重建第二套備庫的Cache Group，并且直接從物理庫刷新數(shù)據(jù)到Cache Group，完全避免了重建Cache Group的遷移或重建操作，更無需受制于內存庫Cache Group的大小影響。

經(jīng)過嚴格的評估與測試，改進后的主-備-備（排除Cache Group復制）方案，在省內多個地市計費業(yè)務系統(tǒng)內存數(shù)據(jù)庫遷移工程中得到應用，并取得良好效果。

（1）工程實施過程中的停機時間從3-4小時逐步縮短為無需停機時間（僅需要應用程序重新連接一次）。

（2）工程操作可以提前實施，并且可以利用搭建完成的目標內存數(shù)據(jù)庫進行功能與性能方面的測試工作。

（3）實施安全性高，在操作過程中，不對原有生產數(shù)據(jù)庫數(shù)據(jù)做變更，而且原有生產庫始終處于正常運行狀態(tài)，如果切換到新系統(tǒng)出現(xiàn)問題，應用程序可以立即切換回原有內存數(shù)據(jù)庫。

4 結束語

本文在研究Timesten內存數(shù)據(jù)庫各個組件功能與實現(xiàn)方式的基礎上，結合業(yè)務場景的具體需求，通過合理設計與多次嘗試，逐步減少由遷移工程造成的業(yè)務中斷時長，最終將其從3-4小時降低到分鐘級別，并成功應用于生產系統(tǒng)的工程實踐中。

表1

核查變更結果，并再次檢查業(yè)務是否正常。a)檢查操作前庫表備份記錄文件是否存在b)檢查Cache Group刷新狀態(tài)c)核查復制策略是否排除所有Cache Group停止并刪除原備庫a)刪除備節(jié)點Cache Group。drop active standby pair; 之后逐個刪除Cache Group：drop cache group XXX;b)備節(jié)點重啟Cache agent進程c)備節(jié)點Cache agent進程停止d)備節(jié)點做ckpt：call ttckpt e)Unload備節(jié)點DSN實例f)Destroy備節(jié)點DSN實例g)停止TT內存庫daemon主進程h)重啟TT內存庫daemon主進程更改主節(jié)點復制策略，并重新開啟復制進程（在復制策略中新增第二套備庫，由主-備策略變?yōu)橹?備-備策略）過程如下：a)刪除原復制策略b)新建主備備復制策略，subscriber為第二套備庫節(jié)點c)設置原主庫仍為主節(jié)點d)啟動內存庫復制進程。a)執(zhí)行備節(jié)點的備機重建腳本 （重建第一個備庫）b)開啟備節(jié)點Cache agent進程和復制進程，包括：開啟TT內存庫Cache agent進程、開啟TT內存庫復制進程。c)檢查備節(jié)點角色狀態(tài)、主節(jié)點檢查復制日志是否進行同步。d)設置主備節(jié)點不自動重啟加載e)等待主節(jié)點復制同步完成。在目標服務器上建立第二套備庫，主庫為原來的生產庫。重建原備庫，開啟復制進程。將備庫原來從主庫刷新數(shù)據(jù)，變更為從物理數(shù)據(jù)庫刷新數(shù)據(jù)。a)建立第二套備庫：ttRepAdmin -duplicate -from -host server1 -uid ttuser -pwd ttuser -nokeepCG b)開啟復制進程并檢查備節(jié)點角色狀態(tài)刪除第二套備庫上面的Cache Group實體表。由于此備庫（subscriber）是read-only狀態(tài)，原Cache Group會直接變?yōu)閷嶓w表，所以需要刪除所有Cache Group實體表再重新搭建CG。需要逐個刪除第二套備庫上面的Cache Group實體表，Drop table XXX。在第二套備庫上配置并創(chuàng)建與物理數(shù)據(jù)庫的連接 在第二套備庫上啟動cacheagent并創(chuàng)建Cache Group表ttadmin -cachestart ${DSN}ttisql "DSN=${DSN};UID= XXX;PWD= XXX;"CREATE CACHE GROUP XXX......重啟cache agent ttadmin -cachestop ${DSN}ttadmin -cachestart ${DSN}數(shù)據(jù)裝載，從物理庫刷新數(shù)據(jù)到每個Cache Group。LOAD CACHE GROUP XXX;commit every 2560 rows parallel 16;......重啟cache agent ttadmin -cachestop ${DSN}ttadmin -cachestart ${DSN}收尾及其他工作a)檢查cachegourp狀態(tài)、日志是否有報錯、數(shù)據(jù)對比等檢查。b)第二套備庫數(shù)據(jù)統(tǒng)計信息收集。c)在工程實施時段內，停止原有內存生產數(shù)據(jù)庫與備份數(shù)據(jù)庫。d)將目標服務器上的第二套備庫轉換為主庫，對外提供數(shù)據(jù)服務。e)切換應用程序，連接到新的主庫上。f)為新的主庫建立一套新的備用數(shù)據(jù)庫，以提高安全性。g)下線并回收原有主機。