近年来,随着非线性编辑系统、数字摄录设备、数字音频工作站、数字演播室、数字切换台的发展,电视节目制作过程中的各个环节已经可以实现全数字化。视频压缩技术和光纤网络技术的不断革新,给电视台传统的制作、存储、播出方式带来了巨大的冲击。电视节目制作的数字化、网络化已是大势所趋,非线性编辑系统网络化带来的优势也是显而易见的,可以降低成本、提高多人协作的工作效率、加强制作过程中不同岗位之间的沟通交流,还可以提高对关键制作流程的管理。其中,作为网络体系结构的一个核心部分,数据库安全技术在节目制作网络化建设中扮演了关键性的角色。本文将结合云南电视台节目制作系统实际情况,重点分析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