使用内存盘提高数据库可用性 在讨论将数据镜像到内存时，人们往往注意到其对性能的提高。但是，谈到可用性时，第一感觉一般是，一旦宕机，未写到磁盘的数据就会全部丢失，其安全性和可用性非常值得怀疑。但是，实际情况是，运用 DB2 数据库的特性，进行一些相关配置，不但可以避免宕机的数据损失，甚至可以大大提高数据库的可用性。下面就详细描述使用内存盘提高数据库可用性的配置方法。
避免宕机造成的数据丢失 从硬件角度讲，一旦宕机，内存中所有的数据都会丢失。使用内存盘的用户也会碰到同样的问题。幸运的是，DB2 提供了一种叫做“归档”的日志类型。在这种情况下，不活动的日志，不是被删除，而是被转移到别处，保存起来。这样，对于内存盘使用者来说，可以讲日志归档至硬盘。这样，即使机器宕机，用户可以用早先备份的数据库文件 ( 或设备 )，恢复数据库，并使用归档日志，将数据库 rollforward 到特定时间点。从而避免宕机引起的数据丢失。
配置归档日志
用户可以选择多种方式对日志进行归档。其中，备份到磁盘是相对简单的方法。用户可以指定将归档日志备份至指定的目录。
db2 update db cfg using LOGARCHMETH1 DISK:/db2backup/archlog
对于，内存盘用户来说，使用归档日志，会影响性能。因为，系统将文件由内存盘拷贝到磁盘时会消耗一些系统资源。但是，通常情况下，这种影响非常小。首先，只有不再具有活动事务的日志文件才会被归档，因此归档操作不会引发对日志文件的共享冲突。其次，在现在的硬件系统上，读写硬盘消耗的 CPU 资源非常小；而且还可以与其他进程并行进行，这意味着归档对数据库的其他读写操作影响很小。
但是，尽管如此，在一种特殊情况下，归档操作仍然会极大的影响性能。例如，活动日志几乎被用满时，写操作需要新的活动日志文件。但是，没有被归档的日志文件不能被重用。此时，就会发生因等待日志归档造成的性能损失。但是，现实中发生这种极端情况的可能性非常小。用户可以通过减小单个日志文件的大小，并增加整个活动日志的大小，来减小这种情况发生的概率。
另外，归档日志并不能保证将数据恢复到故障发生的时间点，这主要发生在，磁盘故障时，以及有多个排队等待归档的日志时。
宕机恢复
如果配置了归档日志，宕机恢复就相对简单。当系统恢复以后，用户需要重现建立内存盘，mount 到目录，并确认其权限。在恢复数据库时，首先，用户需要最新的数据库备份文件，并将其恢复。然后，用户需要通过前滚操作，恢复到指定的时间点，或归档日志的末尾。
前滚到指定时间点：
db2 rollforward db testdb to 1998-04-03-14.21.56 and stop
前滚到日志文件末尾：
db2 rollforward db testdb to end of logs
解除前滚挂起状态：
db2 rollforward db testdb complete
有关与前滚操作的详细信息，读者可以参考 DB2 Information Center。
如果，用户使用操作系统命令保存内存盘上的数据。那么，用户使用需要分割镜像。具体操作方法请参加 DB2 Information Center。
避免单点崩溃造成的数据丢失 为避免单点崩溃造成的数据丢失，DB2 数据库提供了多种解决方案。包括，日志镜像、HADR、Q replication 和 SQL replication。但是，无论哪种方法，都是基于日志备份和 / 或日志重放的。前面已经说过，将日志存放在内存盘上，可以提高日志文件的读写速度，避免对日志文件读写造成的 IO 冲突，从而减小高可用性配置方案对性能的影响。扩展来想，还可以使用另一台机器上的内存盘，来保存数据库镜像日志或归档日志，从而避免单点崩溃造成的数据损失。
NFS+ 内存盘
在一台已经配置了内存盘，并 mount 到特定目录的机器上配置 NFS Server 的步骤，与普通的配置 NFS Server 方法完全相同。
1. 把内存盘的目录，加到 /etc/exports 文件中
/db2data/mirrlog *(rw,no_root_squash,sync)
2. 启动 Portmap 和 NFS
/etc/init.d/portmap start/etc/init.d/nfs start
配置 NFS Client 的步骤：
1. 把远程机器的目录，加到 /etc/fstab 文件中
192.168.1.1:/db2data/mirrlog /db2data/mirrlog nfs defaults 0 0
2. 执行 mount 命令
mount /db2data/mirrlog
同样，NFS 在本地的挂接点，对于 DB2 数据库来说和本地目录没有什么区别。需要注意的是，内存盘的速度大大快于 100M 网络的速度。因此，进行这种配置的时候，至少应保证 NFS Server 和 Client 之间的网络联接速度是 1000Mbps。
日志镜像
在宕机时，内存盘上的数据会丢失，即使配备了归档日志，所有未归档的事务仍会丢失，即使该事务已经 commit。有一个简单方法可以防止发生这种情况：日志镜像。日志镜像通过将日志写到 2 个不同的目录，来避免活动日志损坏。用户可以选择 NFS+ 内存盘作为镜像日志目录。这样有以下几个好处：
- 在千兆网中 NFS+ 内存盘比本机磁盘快的多。使用 NFS+ 内存盘，可以避免写镜像日志时的磁盘 IO，从而提高数据库性能。
- 使用 NFS+ 内存盘作为镜像日志，可以避免因本机硬件故障造成的数据丢失。
- 与使用磁盘做日志镜像相比，前滚速度更快。
用户可以使用以下命令修改日志镜像目录 ( 修改这个参数后，需要重新启动数据库才能生效。)：
db2 update db cfg using MIRRORLOGPATH /db2data/mirrlog
接管
在一个双机环境中，主机发生故障时，往往希望备份机能接管主机的业务，并进行操作。DB2 为此提供了 HADR。毫无疑问，HADR 是一个灵活，简便，可以实现快速接管的解决方案。为此，HADR 需要一个活动的备份数据库。任何在主机上完成的事务，都会在备份机上立刻进行重放，以便在主机发生故障时，备份机能立刻接管主机的业务。但在实际的业务环境中，有时对接管的时间要求并不是非常严格。比如，在备份机接管前，有的客户可以忍受 10 几分钟甚至更长的时间。那么，可以使用数据库备份文件，归档日志和镜像日志，将数据库在备份机上恢复到故障发生前的状态。然后，让备份机接管主机业务。如果数据库在内存盘上的话，整个过程的时间会大大缩短，从而减小接管时间。并且，因为不需要在备份机中维持一个活动数据库，可以大大节省机器资源。
如果，采用这种配置方案，应保证，最新的数据库备份文件和归档日志，在主机故障时可以被访问。这通常要求，把数据库备份文件和归档日志存放在冗余磁盘阵列 (RAID) 上。当检测到主机故障时 ( 手工的或自动的 )，在备份机上，建立内存盘，恢复数据库并前滚。然后，就可以启动备份机数据库，并接管主机业务。 |
