MaxDB有关高可用性

High Availability

Use

高可用性指一个IT系统可以无故障的被连续使用。系统故障包括：

硬件错误（硬盘损坏，掉电，CPU故障，内存故障）

逻辑错误（需要的软件被删除、需要的数据被删除，倒入了错误的数据）

Activities

为了降低可能的系统故障，最小化故障的影响，可以预防硬件级和逻辑级的问题。

高可用性超出了预警的级别，这些操作通常对大的或者特别的危急的系统有作用。

Maxdb提供两种高可用性的方案：

建立一个standby实例

通过集群软件建立一个hot standby系统

ITPUB个人空间:z2Ie8OaU:G

Tips for Avoiding System Failures

Use

为了降低可能的系统故障，最小化故障的影响，可以有以下的选项：

n 数据和日志区使用不同的硬盘

n 使用基于硬件的日志区和数据区的镜像，比如RAID-5、RAID-1等。当使用RAID的时候，注意RAID控制器有好的写性能，且caches在掉电的时候还可以被保存到硬盘。

n 如果使用fault-tolerant硬件，则使用相同类型的硬件扩展容量，比如只用RAID-5系统扩展RAID-5系统

n 为系统选择合适的日志设置

² 如果不能实现基于硬件的镜像，则配置日志模式使日志区使用基于软件的镜像。

² 关闭日志区的覆盖模式

² 使重做日志管理永远打开

n 为数据库系统设置合适的备份和管理方案。

 

Standby Databases

Use

Standby数据库是当前活跃实例的一个拷贝。

定期通过从原始实例传过来的日志备份更新standby实例。Standby实例的状态一直处于ADMIN状态。

如果原始实例故障，可以立即激活standby实例，可以减少数据库down掉的时间。可以配置standby的状态是原始数据库在过去某一点的状态。

Original instance and standby instance

 

 

Setting Up A Standby Instance

Procedure

使用DBM工具创建standby：

1、 通过创建一个原始实例的拷贝创建一个standby实例。但是先不要将该实例转换到ONLINE的状态，只使该实例在ADMIN的状态。

² 推荐建立原始实例和standby实例在不同的机器上

² Standby实例必须不能获取原始实例上的相同文件，也就是说必须设置不同的运行路径

2、 在standby实例上，创建一个备份介质并倒入日志备份。

Updating the Standby Instance

Procedure

1、定时在原始实例上创建日志备份。

2、定时将这些备份倒入到standby实例。（通过ftp或者其他方式传输，软件没有提供）

Activating the Standby Instance

Procedure

使用DBM执行下列步骤：

1、 依赖于原始数据库的状态和配置，你可以有以下的选择：

² 倒入原始实例的一个手工log备份

² 倒入截至到当前点的日志备份

² 拷贝原始实例的日志卷

以上三个选择的操作在下面详细的介绍了。

2、 修改standby实例的状态到ONLINE

3、 如果可能，修复standby实例中所有不适最新的索引

4、 创建standby实例的完全数据备份。

注意：

在创建一个完全的数据备份之前，不能创建日志备份。

 

这里提到如果需要把原来的实例做成standby实例，需要按照上面的步骤重建，也就是没有提供主从数据库之间的双向切换。

Importing an Additional Manual Log Backup

Use

如果你还可以在原始实例创建另外一个交互式的日志备份，则你可以在standby数据库激活的时候没有数据丢失，也就是和主数据库有着相同的状态。

Prerequisites

² 已经建立了一个standby实例

² Standby实例还没有被激活过

² 原始实例的日志卷没有被破坏

² 可以通过交互式的方式创建原始实例的日志备份

Procedure

1、 在原始实例创建一个交互式的日志备份

2、 在standby实例上倒入日志备份

Importing Log Backups up to a Certain Point in Time

Use

如果想要恢复standby实例到原始实例之前的某一个状态，比如说误删除数据之前的状态。

Prerequisites

已经建立了一个standby实例

Standby实例还没有激活到ONLINE状态

已经在standby实例上倒入了在你需要的时间点之前的日志备份

Procedure

1、 如果你设置了日志备份自动倒入standby实例，则需要cancel这个自动恢复。

2、 倒入截至到你需要的时间点的日志备份。

Copying the Log Volumes of the Original Instance

Use

如果原始实例上的日志卷没有损坏，且可以通过操作系统传输到standby实例所在的机器上，你就可以在无丢失任何数据的情况下激活standby实例或者激活standby实例到过去的任何一个时间点。

Prerequisites

² 已经建立了一个standby实例

² Standby实例还没有被激活到ONLINE状态

² 原始实例的日志卷没有被破坏

² 两个实例的日志卷的大小完全一样

² 原始实例在OFFLINE状态

Procedure

1、 如果你设置了日志备份自动倒入standby实例，则需要cancel这个自动恢复。

2、 修改standby实例的状态到OFFLINE

3、 倒入standby实例上缺少的日志备份。

4、 通过操作系统方式拷贝原始实例上的日志卷到standby实例

5、 重启standby实例

Identifying Log Backups Since the Last Savepoint

Use

标识出从standby实例中最后一次保存点的日志备份，顺序的倒入这些日志备份可以使standby实例达到最终的状态。

注意：数据库系统为日志备份编号并且记录在日志历史中

Prerequisites

原始实例上的日志历史没有被破坏

Procedure

使用命令行界面执行以下命令：

1、 登陆standby实例

2、 从重启记录或者standby实例显示数据，命令是：db_restartinfo

Used LOG Page 显示了第一个会被读入的日志页号码

Used LOG Page 1157
:u(K0z1^t9n N0First LOG Page 2147483647
AWu'GAP-n0Restartable 1
u+]nlEw0Id Restart Record mycomputer.mynet:HOTELDB_20040712_141643ITPUB个人空间5Smobp F+iZ%Pb
Id LOG Info mycomputer.mynet:HOTELDB_20040712_141643ITPUB个人空间 K9]eOK8_0P| P
Consistent 1

3、 使用命令行界面登陆到原始实例

4、 显示原始实例的日志历史

backup_history_open
%ZWpvo /A0backup_history_list
5K rB$L ob8h0backup_history_close

日志历史详细说明了日志页被包含在那个日志备份中

[...]

40F281390005|LOG_00002|SAVE WARM|2004-07-12 13:59:07|2004-07-12 14:16:57|2004-07-12 14:16:57|2004-07-12 14:16:58|989|1157| |auto|64|1|0| |

[...]

几个日志备份会使用备份介质从数据库实例中取出，日志备份LOG_00002包含日志页1157，因此会被第一个倒入，日志备份LOG_00003，LOG_00004随后也可以被倒入。

Example: Standby Database

下面是一个如何使用命令行工具设置一个standby实例并激活的例子：

Prerequisites

前提是你已经有一个数据库实例可以用来作为standby实例。

Procedure

1、 修改standby实例的状态到ADMIN状态：

db_offlinedb_admin

2、 在standby实例上为倒入原始实例的完全数据备份创建一个备份介质

medium_put <medium_name_data> <path_data> <medium_type> DATA

3、 初始化存在的standby实例，从原始实例上倒入最后一次备份

db_connectdb_activate RECOVER <medium_name_data>

4、 在standby实例上为倒入原始实例的日志备份创建一个备份介质

medium_put <medium_name_log> <path_log>save.log FILE LOG

5、 检查被倒入的日志文件的号码

a) 在standby上执行：db_restartinfo

b) 在原始实例上显示日志历史：

dbmcli -d <database_name> -u <dbm_user, dbm_user_password>backup_history_openITPUB个人空间Tj]3{9|2N
backup_history_list
oM&p/SD6r~$x(s.b/b0backup_history_close

6、 倒入日志备份

db_offlinedb_admin
S/t s X(j|A1} ^lc#?0db_connect
joUo%Q/Z'Bm /8?"@0recover_start <medium_name_log> LOG 001
pD;Mu)Ik8H0recover_replace <medium_name_log> <path_log>save.log 002
1ZI0~
l3I3B$PW}0recover_replace <medium_name_log> <path_log>save.log 003
K*z _1d,h'r/0...

7、 激活standby实例，取消倒入日志备份，并切换到ONLINE状态：

recover_ignore

Hot Standby

Use

Hot standby是运行在并行模式下的，如果主数据库实例故障，可以快速切换到standby实例。

一个HOT STANDBY是由一个活跃的主实例和一个或者多个standby元件组成，它们配置成一个集群，从外表上看和单独得数据库实例是没有什么区别的。

当主实例有故障的时候，从元件可以快速而自动的替代主元件且没有数据丢失，这一实现是通过集群软件的故障转移机制来保证的。

Activities

建立一个数据库实例作为主元件，然后增加需要数量的从元件。当一个新的standby元件被初始化的时候，内存管理系统拷贝主元件的全部内容到从元件以保证一致性，比如 状态、最后的保存点等。

主元件和从元件使用相同的日志区，从元件定时使用主实例的日志自动更新。

System Requirements for a Hot Standby System

要建立HOT STANDBY，除了MAXDB数据库软件之外还需要集群解决方案和内存管理系统。

Database Software

HOT STANDBY系统从MAXDB的7.5.0.8版本开始可以建立

Cluster Solution

集群解决方案使多个物理元件可以被逻辑的链接，一个HOT STANDBY系统由集群系统中两个或者多个元件组成。

集群软件必须提供专门的故障转移机制，使得主从元件在出现错误的时候可以切换功能。集群软件不断的监控hot standby元件是必要的，在集群软件中主从元件有不同的IP地址，集群软件必须支持IP地址的切换。

以下提到的maxdb集群解决方案是在IBM高可用性多进程集群系统软件上测试的。

Memory Management System

主从元件的卷必须使用满足以下条件的内存管理系统：

² 元件可以同时获取日志区

² 它们获得两个不同的执行权限：只读和读写

² 每个数据卷有它自己的物理内存区域

² 数据卷可以通过相同的名字或者建立的对应的符号链接被寻址

² 可以创建数据卷的一致性拷贝（SPLIT）。当拷贝被创建的时候，主元件可以连续的写入它的数据卷以保证down时间最短。在split之后，主从元件的数据卷是完全独立的。

² 当从元件被初始化或者出现错误的时候，大量数据集需要被拷贝。这就是为什么内存管理系统需要能使得数据被快速拷贝和快速加工。

 

下面的提到的满足要求和支持创建hot standby系统得内存管理系统是：EMC Symmetrix, IBM TotalStorage Enterprise Storage Server (ESS), IBM TotalStorage SAN Volume Controller (SVC).

Architecture of a Hot Standby System

一个HOT STANDBY是由一个活跃的主实例和一个或者多个standby元件组成，它们配置成一个集群，从外表上看和单独得数据库实例是没有什么区别的。

在集群系统中，每个的元件和其他元件通过内部的本地的地址通讯。

访问HOT STANDBY需要下面的信息：

n 实例的名字(下图中的HOTELDB)

n 虚拟的服务名（下图中的HOTEL_VIRTUAL）：表示当前的主元件，如果主元件故障，则虚拟的服务名切换到从元件，代替主元件的工作。

Example of setting up a hot standby system

 

从元件在standby状态，该状态对应得是ADMIN和ONLINE之间的一个状态。在STANDBY操作状态的从元件不是一个实际的实例，只有在主实例故障的时候，从实例才会转变成一个可用的实例。

主元件和从元件使用相同的数据库参数，要修改数据库参数，只需要在主元件上执行对应的DBM命令，系统可以将修改自动传输到所有其他的从元件。

主元件和从元件使用相同的日志区，但是从元件只有读权限。

注意：

与hot standby 数据库不同，普通 standby的所有实例都拥有各自独立的日志区。

为了避免硬件错误，我们推荐在hot standby系统中镜像日志区。

 

主元件和从元件都各自有独立的数据区，他们也都有自己的kernel，cache，单独的X server,DBM 服务器等等。

Access to a shared log area

 

Synchronizing Master and Standby Components

Use

数据库系统同步主元件和从元件，主元件写入的日志区会自动倒入到从元件，使对应的操作在从元件中执行。

从元件中的数据集和主元件的数据集是对应的（有一定的延迟），可以使用HS_DELAY_TIME参数设置延迟的时间值。

注意：

与hot standby不同，普通的standby数据库日志是从备份介质倒入的。

Activities

数据库系统在固定的时间间隔启动同步，主元件有规律的通知从元件（通过HS_SYNC_INTERVAL参数设置）新的日志写到哪个点。从元件报告他们已经读日志到哪个点，然后倒入日志到当前点（通过设置HS_DELAY_TIME决定延迟时间），然后执行对应得操作。

主从元件使用相同的数据库参数，如果一个新的standby元件被建立，他将收到一份主元件的参数的完全拷贝。只需要在主元件上进行参数调整，这些调整会自动传输到从元件。

Behavior of the Hot Standby System if an Error Occurs

Purpose

如果HOT STANDBY系统得主元件停掉了，其中一个从元件会自动代替主元件的功能。

HOT STANDBY配置不提供对人为错误和应用错误的任何保护，要阻止这些错误的危害，需要定期对数据和日志提供备份。如果一旦发生类似的错误，你需要恢复数据和日志到发生错误的时间点。

Process Flow

集群软件会持续的监控HOT STANDBY的主元件。

1、 当主元件故障的时候，集群软件定义其中一个从元件作为新的主元件并且发送对应得信息给所有的从元件。

2、 新的从元件使用主元件的虚拟服务名，外部系统也使用该虚拟服务名寻址。

3、 从元件被赋予对日志区的写权限并读取最后一个还没有读的日志，所有的进程都被提交以结束进程。

4、 数据库系统修改从元件的执行状态到ONLINE。

 

 

通过学习可以了解的主要是：

1、 maxdb的高可用性通过两种机制来实现：

sa) standby

b) hhot standby

 

2、standby这种方式和oracle的standby方式很像，都是一个以特殊方式启动的实例，有自己单独的数据文件和日志文件，通过主实例传输过来的日志文件进行同步，当主实例出现问题的时候，从实例转换成一个主实例需要一定的时间。与oracle不同的是他的软件本身没有提供日志文件的传输的方式，像是需要通过自己定义操作系统集的传输方式。如果主元件所在服务器上的日志文件在出现故障的时候损坏，则会存在数据的缺失。

由于我在实验数据库的备份和恢复的时候一直都没有成功，所以一直也不能成功建立standby数据库。

 

3、Hot standby的方式和oracle的rac有点儿类似，不同的是主从实例之间只是日志文件共享，数据文件是不共享的，从元件同样是通过执行主元件的日志实现和主元件的同步，区别是在主元件出现故障的时候，从元件可以自动切换到主元件，对于应用来说是透明访问的，但是我仍然觉得这个切换的过程还是有时间间隔的，因为日志文件不是传输到从元件的服务器上的，所以主元件服务器的故障不会损坏日志文件，理论上不会有数据的缺失。

但是HOT STANDBY的实现是要依赖于集群服务器和内存管理系统的，他自己本身并不提供。这使我们的测试有一定的难度。