数据库安全实战：详解IBM SolidDB的Standby特性

 

通常人们理解的数据库安全有两层含义，一是系统运行安全，二是系统信息安全。而实际上，高可用性也是数据库安全的一部分内容。当第一台服务器发生故障时，数据库高可用性可以保证另一台服务器立即接替工作，这项技术通常成为standby。

IMDB最大规模的应用集中在电信领域，尤其以计费系统为主。当然，近些年陆续开始向新的电信业务领域拓展，例如核心网、CRM、精确营销等。下图是IMDB在电信计费中的架构图，供大家参考。

    

     以某移动通信的计费系统为例，该公司的出账系统架构采用的是基于内存数据库的灾备设计策略。即在两个内存数据库之间建立复制关系，采用Standy的HA方式，实现同步数据。HA切换方式可通过应用层实现，也可通过第三方HA软件或手动实现。这样，一旦主节点由于意外不可用，可立即切换到备份节点恢复应用。主备节点分别将恢复日志持久化到磁盘阵列。

下面，我们探讨一下比较成熟的内存数据库产品——IBM公司的内存数据库solidDB的高可用性，如下图所示。

可以看到，与大多数据数据库一样，solidDB的standby也涉及到主数据库和备数据库的主从关系，其中，主数据库可读可写，而从数据库的特点是只读，充当主数据库的镜像。Watchlog实际上是一个后台进程，监视住从服务器的运行与负载情况，并在必要时切换他们的状态，从而减轻了管理员监视服务器的负担。

从solidDB服务器的状态来看，主数据库存在三种状态：PRIMARY ACTIVE，PRIMARY ALONE，PRIMARY UNCERTAIN。其中，PRIMARY ACTIVE指的是主服务器正在接受读写事务，并且在向从数据库读写数据。此时，从数据库必须处于SECONDARY ACTIVE 状态。PRIMARY ALONE指的是对等服务器之间未互相连接。意思是主数据库正在积极接受与执行读写事务，而从数据库未接受任何事务，即与主数据库之间并未建立连接。事务会延迟发送至备份数据库。PRIMARY UNCERTAIN值得是服务器之间经历异常而断开连接。在PRIMARY UNCERTAIN状态下，任何未经确认的事务将保持暂挂状态，这意味着该服务器状态被改变之前，此服务器将不会落实或者回滚事务。

SECONDARY ACTIVE的概念与PRIMARY ACTIVE类似，指的是从服务器正在接受来自主服务器的事务日志读写，这也意味着主服务器必须处于PRIMARY ACTIVE状态。SECONDARY ALONE指的是从服务器与主服务器断开，不过可以通过HotStandby connect命令连接主服务器。作为从服务器，只接受读取请求。

接下来，我们结合solidDB提供的Shell，举例说明上述几种状态的切换。

首先，为了让主从服务器都处于ACTIVE状态，通过在任一服务器中发出 hsb connect 命令将主数据库连接至备数据库。可以通过输入 hsb status connect 命令来检查 hsb connect 的状态。要验证连接是否成功，可输入 hsb state 命令，如下：

ADMIN COMMAND 'hsb connect';

ADMIN COMMAND 'hsb status connect';

ADMIN COMMAND 'hsb State';

如果将主数据库切换到 PRIMARY ALONE 状态，可以执行下列命令：

ADMIN COMMAND 'hsb set primary alone';

相应地，如果将从数据库切换成SECONDARY ALONE状态，可以执行下列命令：

ADMIN COMMAND 'hsb set secondary alone';

当然除了solsql脚本外，我们也可以使用solcon控制台，对应的命令如下：

1） 连接主数据库和备数据库

>solcon – e”hsb connect” “tcp 1320” dba dba   

>solcon – e”hsb status connect” “tcp 1320” dba dba   

>solcon – e”hsb state” “tcp 1320” dba dba 

2）切换主数据库状态

>solcon – e ”hsb set primary alone” ”tcp 1320” dba dba 

3）切换主数据库状态

>solcon – e ”hsb set secondary alone” ”tcp 1320” dba dba 

总之，随着硬件成本的降低，内存数据库应用越来越广泛，而作为数据灾备中重要的一环，数据库的高可用性（即Standby）自然也是诸如solidDB之类的内存数据库所有考虑的重要特征。