DB2使用内存盘提高OLTP数据库的性能和可用性_2

使用内存盘提高数据库可用性

在讨论将数据镜像到内存时，人们往往注意到其对性能的提高。但是，谈到可用性时，第一感觉一般是，一旦宕机，未写到磁盘的数据就会全部丢失，其安全性和可用性非常值得怀疑。但是，实际情况是，运用 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 几分钟甚至更长的时间。那么，可以使用数据库备份文件，归档日志和镜像日志，将数据库在备份机上恢复到故障发生前的状态。然后，让备份
4000
机接管主机业务。如果数据库在内存盘上的话，整个过程的时间会大大缩短，从而减小接管时间。并且，因为不需要在备份机中维持一个活动数据库，可以大大节省机器资源。

如果，采用这种配置方案，应保证，最新的数据库备份文件和归档日志，在主机故障时可以被访问。这通常要求，把数据库备份文件和归档日志存放在冗余磁盘阵列 (RAID) 上。当检测到主机故障时 ( 手工的或自动的 )，在备份机上，建立内存盘，恢复数据库并前滚。然后，就可以启动备份机数据库，并接管主机业务。

 

回页首

 

总结

本文描述了如何使用 Linux 内存盘 (Ramdisk)，配置 DB2 数据库服务器。毫无疑问，在决定是否使用内存盘配置业务数据库之前，用户有必要对这种配置方法的优点和缺点做一个全面的了解。而且，首先需要了解这种配置方法的一些限制。

使用内存盘的限制：

内存盘需要占用大量的内存。通常，为了避免内存被过度占用，用户应保证内存盘占用的内存，最多不超过物理内存的 4/5( 假设在机器只作为数据库服务器，且仅有一个数据库 )。并且，用户应保证为操作系统和数据库服务器留下至少 1G 以上的内存。

网络速度至少是 1000Mbps。

不同的 Linux 对内存盘的大小有不同限制的，尽管这个限制可能远远大于物理内存。通常，这个限制大约是 100G 左右。

因为，使用大 Bufferpool 已经可以有效的提高读速度。因此，使用内存盘对提高读速度不明显。因此，在数据仓库系统，或者任何读操作为主的系统中不建议使用内存盘。尽管如此，内存盘对提高导入速度有明显的作用。在导入速度是主要瓶颈的系统中，用户仍然可以考虑使用内存盘。

内存盘相对于高端的磁盘阵列 (RAID)，并没有明显的性能优势。

实际上，除了配置内存盘外，用户可以选择使用大的 Bufferpool 加快数据库的读写速度。下面比较这两种方法的优缺点：

对比建立在以下基础上：

系统具有足够内存。

Bufferpool 进行了正确的配置。

使用大 Bufferpool 的操作，已经将所有数据镜像到 Bufferpool。

在所有数据镜像到 Bufferpool 以后执行了 runstats 操作。

使用内存盘的，在数据库启动以后，进行了 runstats 操作。

表 1. 内存盘和大 Bufferpool 的对比

对比项	使用内存盘	使用大 Bufferpool
多并发查询	速度很快，但与使用大 Bufferpool 相比没有明显优势。	速度很快
复杂查询	速度很快，但如果因为节省内存，没有明显优势	速度很快
多并发修改	速度很快，基于修改字段的不同，速度相当于使用大 Bufferpool 的 1-5 倍	速度比较快
多并发插入	速度很快，基于数据和表结构的不同，速度相当于使用大 Bufferpool 的 2－20 倍	速度一般
多并发删除	速度很快，基于数据和表结构的不同，速度相当于使用大 Bufferpool 的 2－20 倍	速度一般
内存使用	很大，至少相当于使用大 Bufferpool 的 2 倍	比较小
避免高可用性配置对性能的影响	很好，获取日志，对主机的性能几乎没有影响。但如果主机需要等待备份机重放，对性能仍然有显著影响	很差，获取日志对系统性能影响很大，即使使用比较大的 Logbuffer 也是如此。

 

结论，内存盘配置方法，适合那些内存非常多的，对效率和并发有特殊要求的用户。但随着硬件成本的降低和业务的发展，这种用户可能会逐渐增多。另外，建议用户在把内存盘数据库作为实际业务系统的配置之前，做充分的测试 ( 包括性能测试 )，毕竟未考虑到的因素，可能会影响系统的稳定和性能。