近年來，隨著非線性編輯系統、數字攝錄設備、數字音頻工作站、數字演播室、數字切換臺的發展，電視節目制作過程中的各個環節已經可以實現全數字化。視頻壓縮技術和光纖網絡技術的不斷革新，給電視臺傳統的制作、存儲、播出方式帶來了巨大的沖擊。電視節目制作的數字化、網絡化已是大勢所趨，非線性編輯系統網絡化帶來的優勢也是顯而易見的，可以降低成本、提高多人協作的工作效率、加強制作過程中不同崗位之間的溝通交流，還可以提高對關鍵制作流程的管理。其中，作為網絡體系結構的一個核心部分，數據庫安全技術在節目制作網絡化建設中扮演了關鍵性的角色。本文將結合云南電視臺節目制作系統實際情況，重點分析HADR技術在提高非編網絡系統數據庫安全性、可用性等方面的作用。
一. 數據庫在節目制作系統中的重要作用
就云南電視臺全臺網而言，從計費系統的人員管理、到新聞網Interplay的素材索引信息、再到直播系統中的視頻ID信息、收錄系統的排單信息、以及非編網的素材存儲、空間分配、權限管理等，都需要數據庫技術的支持。如果數據庫出現故障，輕則素材信息丟失，重則節點癱瘓，節目制作流程受阻。
以云南電視臺索貝制作網為例，采用了兩臺DELL Power Edge 2950作為DB2數據庫服務器，主要表空間及對應數據內容如下：
二. HADR技術原理
HADR（High Availability Disaster Recover）高可用性災難恢復是DB2數據庫系統用于雙機互備、故障恢復的一種解決方案。HADR環境需要至少兩臺DB2服務器搭建，分為主機和備機。兩臺服務器通過HADR機制實現數據同步和故障切換。
HADR在雙機工作時把主機（Primary）已經提交的事務通過日志的形式基于TCP/IP傳送給備機（standby），通過DB2自帶的前滾功能在備機上重新執行主機已經提交的數據而達到與主機同步的狀態，并在主機發生故障時，能夠迅速在保障數據一致性的前提下接管主機的工作。
HADR支持三種工作方式：Synchronous，Near Synchronous，和Asynchronous Synchronous mode：同步模式針對數據丟失提供了最高的保護。在同步模式，只有主服務器成功寫入數據，并且收到備份服務器也成功寫入的確認后才會寫入日志。 Near Synchronous mode：接近同步模式下，當主服務器成功寫入數據，并且收到事務已寫入備份服務器的內存的確認后才會寫入日志。 Asynchronous mode：異步模式提供對數據最低級別的
保護，但卻能提供最好的性能。在Asynchronous 模式下，向主服務器和TCP/IP堆棧寫入任何事務日志都是成功的，不受備服務器影響。
索貝制作網采用NEARSYNC(接近同步)方式，當主數據庫日志寫入成功，并收到備用數據庫的應答，確定備用數據庫已經接收到日志時，才認為日志寫入成功。這種方式下的事務響應時間比SYNC方式短，且僅當兩臺服務器同時發生故障時，才會發生事務丟失。
三. HADR的建立機制
DB2的主機和備機在建立HADR的時候都要經過幾個狀態：
備機:
# S-Boot
# S-LocalCatchup（備機在前滾已經傳送到本地的日志）
# S-RemoteCatchupPending
# S-RemoteCatchup
# S-NearlyPeer
# S-Peer
主機:
# P-Boot (was None)
# P-RemoteCatchupPending(was P-Boot)
# P-RemoteCatchup(was P-RemoteCatchupPending)
# P-NearlyPeer(was P-RemoteCatchup)
# P-Peer (was P-NearlyPeer)
RemoteCatchupPending：備機完成了對本地日志的前滾，嘗試與主機建立通訊以獲得后續的日志文件。
RemoteCatchup：備機已經與主機成功建立了連接并正在接受新的日志用于前滾。 NearlyPeer：備機已經完成了所有日志文件的前滾操作，處于等待主機完成暫掛日志寫入和讀取磁盤上日志進行處理的操作。
Peer：根據HADR的同步模式選擇，備機和主機處于對等狀態。
通過從上面的狀態解釋可以看出，主機和備機在建立HADR機制時必須處于對等狀態，否則備機將無法取得主機在建立HADR之前的日志文件。并且，在任何非對等狀態下，主備發生角色互換都是HADR不允許的。因為仍有一部分在主機已經提交的數據操作未能在備機重放，這將造成數據的丟失。同時可以看到HADR在提供數據保護之前是需要一定的時間完成準備的，而這個準備過程是異步的，不隨命令啟動成功而完成，需要用戶通過對db2diag.log或者db2pd來查證確認，直到日志或db2pd中顯示出對等（peer）狀態時，數據才真正處于HADR的保護之下。因此如果進行強制切換的瞬間HADR處于對等之外的其他狀態，這個切換將不可逆，并可能導致只有通過重建HADR來修復HADR環境。
四、HADR環境搭建的基本步驟
以云南電視臺索貝非編網為例：
主數據庫服務器DBServer1，IP 172.16.70.3
備數據庫服務器DBServer2，IP 172.16.70.4
1.修改NETDB數據庫配置參數LOGRETAIN為ON，使該數據庫日志記錄方式改為存檔日志。
2.修改索引日志記錄參數
UPDATE DB CFG FOR NETDB USING LOGINDEXBUILD ON
UPDATE DB CFG FOR NETDB USING INDEXREC RESTART
3.備份數據庫NETDB
BACKUP DB NETDB TO E:\database\dbbak
4.將得到的數據庫映像文件復制到DBServer2對應的目錄下(E:\database\dbbak)。
5.在DBServer2上恢復數據庫NETDB
RESTORE DATABASE NETDB FROM "E:\database\dbbak" TAKEN AT
20100328173525 REPLACE HISTORY FILE WITHOUT PROMPTING
6.配置自動客戶端重新路由
在主數據庫服務器（DBServer1）上執行以下命令：
UPDATE ALTERNATE SERVER FOR DATABASE NETDB USING HOSTNAME
172.16.70.3 PORT 50000
在備用數據庫服務器上（DBServer2）上執行以下命令：
UPDATE ALTERNATE SERVER FOR DATABASE NETDB USING HOSTNAME
172.16.70.4 PORT 50000
7.配置HADR服務和偵聽端口：
在主備數據庫服務器上編輯C:\windows\system32\drivers\etc\services，
加入下面兩行：
DB2_HADR_1???? 55001/tcp
DB2_HADR_2???? 55002/tcp
8.修改主數據庫（DBServer1 - NETDB）的配置參數：
UPDATE DB CFG FOR NETDB USING HADR_LOCAL_HOST 172.16.70.3
UPDATE DB CFG FOR NETDB USING HADR_LOCAL_SVC DB2_HADR_1
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_HOST 172.16.70.4
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_SVC DB2_HADR_2
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_INST ynnetdba
UPDATE DB CFG FOR NETDB USING HADR_SYNCMODE NEARSYNC
UPDATE DB CFG FOR NETDB USING HADR_TIMEOUT 120
CONNECT TO NETDB
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
UNQUIESCE DATABASE
CONNECT RESET
9.修改備用數據庫（DBServer2 - NETDB）的配置參數：
UPDATE DB CFG FOR NETDB USING HADR_LOCAL_HOST 172.16.70.4
UPDATE DB CFG FOR NETDB USING HADR_LOCAL_SVC DB2_HADR_2
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_HOST 172.16.70.3
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_SVC DB2_HADR_1
UPDATE DB CFG FOR NETDB USING HADR_REMOTE_INST ynnetdba
UPDATE DB CFG FOR NETDB USING HADR_SYNCMODE NEARSYNC
UPDATE DB CFG FOR NETDB USING HADR_TIMEOUT 120
10.啟動HADR：
首先啟動備用數據庫服務器的HADR：
DEACTIVATE DATABASE NETDB
START HADR ON DATABASE NETDB AS STANDBY
然后啟動主數據庫服務器的HADR：
DEACTIVATE DATABASE NETDB
START HADR ON DATABASE NETDB AS PRIMARY
五. HADR故障恢復
從HADR的操作規范來看，HADR的主機在發生故障或者由于用戶對備機發出takeover by force命令進行強制接管后應該做的是修復原主機的故障，并以備機身份重新加入HADR。這一操作過程是正確的，但是要成功完成必須具備一定的條件。要正常恢復HADR雙機環境，取決于下面兩個因素：
發生故障時主機和備機處于對等狀態，也就是說主備之間不存在數據落差，這樣主機切換到備機后再加入HADR就不會發生備機（原主機）的日志前滾點比主機（原備機）更新的情況。
發生故障并切換后，對主機的所有訪問請求都被路由到備機，在出現故障并發生切換后，原主機的數據未發生任何更改。此時應手動進行雙機數據同步，才能重新建立對等狀態。
六. HADR模式的不足
DB2 HADR作為一種高可用性的數據恢復模式，能夠在數據庫服務器發生故障時盡可能地搶救數據，挽回損失并保障工作正常進行。但HADR環境下數據庫自身無法自動切換，出現問題時只能人工進行主備切換，這就在一定程度上加大了人員開支和不穩定因素。我們在實際運用中可以結合Tivoli System Automation （TSA）、High Availability Cluster Multi-Processing （HACMP）、Microsoft Windows Server Cluster或者Linux HA等運行環境來實現HADR的故障自動切換。
隨著電視節目制作網絡化的不斷發展，越來越多的電視臺開始構建自己的制作網、播出網甚至全臺網。數據庫安全已經逐漸成為節目制作安全、播出安全的一個重要組成部分。本文結合實際運用，重點介紹了DB2 HADR技術的實現原理、構建方案及改進思路，可廣泛應用于電視臺節目制作系統的各個數據存儲節點，為節目制作數據庫系統提供了一種低成本、高可用的解決方案。B&P