首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

使用内存盘提高OLTP数据库的性能和可用性(3)

使用内存盘提高OLTP数据库的性能和可用性(3)

使用内存盘提高数据库可用性  在讨论将数据镜像到内存时,人们往往注意到其对性能的提高。但是,谈到可用性时,第一感觉一般是,一旦宕机,未写到磁盘的数据就会全部丢失,其安全性和可用性非常值得怀疑。但是,实际情况是,运用 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) 上。当检测到主机故障时 ( 手工的或自动的 ),在备份机上,建立内存盘,恢复数据库并前滚。然后,就可以启动备份机数据库,并接管主机业务。
返回列表