在讨论将数据镜像到内存时,人们往往注意到其对性能的提高。但是,谈到可用性时,第一感觉一般是,一旦宕机,未写到磁盘的数据就会全部丢失,其安全性和可用性非常值得怀疑。但是,实际情况是,运用 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 冲突,从而减小高可用性配置方案对性能的影响。扩展来想,还可以使用另一台机器上的内存盘,来保存数据库镜像日志或归档日志,从而避免单点崩溃造成的数据损失。
在一台已经配置了内存盘,并 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) 上。当检测到主机故障时 ( 手工的或自动的 ),在备份机上,建立内存盘,恢复数据库并前滚。然后,就可以启动备份机数据库,并接管主机业务。
|
本文描述了如何使用 Linux 内存盘 (Ramdisk),配置 DB2 数据库服务器。毫无疑问,在决定是否使用内存盘配置业务数据库之前,用户有必要对这种配置方法的优点和缺点做一个全面的了解。而且,首先需要了解这种配置方法的一些限制。
使用内存盘的限制:
- 内存盘需要占用大量的内存。通常,为了避免内存被过度占用,用户应保证内存盘占用的内存,最多不超过物理内存的 4/5( 假设在机器只作为数据库服务器,且仅有一个数据库 )。并且,用户应保证为操作系统和数据库服务器留下至少 1G 以上的内存。
- 网络速度至少是 1000Mbps。
- 不同的 Linux 对内存盘的大小有不同限制的,尽管这个限制可能远远大于物理内存。通常,这个限制大约是 100G 左右。
- 因为,使用大 Bufferpool 已经可以有效的提高读速度。因此,使用内存盘对提高读速度不明显。因此,在数据仓库系统,或者任何读操作为主的系统中不建议使用内存盘。尽管如此,内存盘对提高导入速度有明显的作用。在导入速度是主要瓶颈的系统中,用户仍然可以考虑使用内存盘。
- 内存盘相对于高端的磁盘阵列 (RAID),并没有明显的性能优势。
实际上,除了配置内存盘外,用户可以选择使用大的 Bufferpool 加快数据库的读写速度。下面比较这两种方法的优缺点:
对比建立在以下基础上:
- 系统具有足够内存。
- Bufferpool 进行了正确的配置。
- 使用大 Bufferpool 的操作,已经将所有数据镜像到 Bufferpool。
- 在所有数据镜像到 Bufferpool 以后执行了 runstats 操作。
- 使用内存盘的,在数据库启动以后,进行了 runstats 操作。
对比项 | 使用内存盘 | 使用大 Bufferpool |
多并发查询 | 速度很快,但与使用大 Bufferpool 相比没有明显优势。 | 速度很快 |
复杂查询 | 速度很快,但如果因为节省内存,没有明显优势 | 速度很快 |
多并发修改 | 速度很快,基于修改字段的不同,速度相当于使用大 Bufferpool 的 1-5 倍 | 速度比较快 |
多并发插入 | 速度很快,基于数据和表结构的不同,速度相当于使用大 Bufferpool 的 2-20 倍 | 速度一般 |
多并发删除 | 速度很快,基于数据和表结构的不同,速度相当于使用大 Bufferpool 的 2-20 倍 | 速度一般 |
内存使用 | 很大,至少相当于使用大 Bufferpool 的 2 倍 | 比较小 |
避免高可用性配置对性能的影响 | 很好,获取日志,对主机的性能几乎没有影响。但如果主机需要等待备份机重放,对性能仍然有显著影响 | 很差,获取日志对系统性能影响很大,即使使用比较大的 Logbuffer 也是如此。 |
结论,内存盘配置方法,适合那些内存非常多的,对效率和并发有特殊要求的用户。但随着硬件成本的降低和业务的发展,这种用户可能会逐渐增多。另外,建议用户在把内存盘数据库作为实际业务系统的配置之前,做充分的测试 ( 包括性能测试 ),毕竟未考虑到的因素,可能会影响系统的稳定和性能。