RealSync对系统资源的占用分析
在关键业务系统中的应用，性能和压力是复制软件的核心，是每天每时每刻都用到的，尤其是在业务高峰期情况下，能否跟得上日志的产生速度、能否不大量的占用系统资源、能否保证复制的及时性是整个数据库复制软件产品最为核心的内容。
根据我们在各种国内的几十家应用情况显示来看DSG RealSync在实时复制方面的性能是同类产品中领先的。主要体现在：
1.1.1 网络需求
RealSync对数据传输采用TCP/IP网络传输。
RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 .
1.1.2 日志分析速度
我们采取了积压日志分析的方式进行测试，利用rac环境下的两台服务器同时产生10GB的日志数据，然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在rac模式下，由两个数据库节点同时工作，在5分钟内产生的10GB归档日志，共计800万条记录，realsync只需要2分钟40秒即能分析完累积的日志，约9分钟装载完成。日志分析的速度远远高于产生日志的速度。完全能够满足用户IT系统的业务需求，即使是在业务高峰期，也不会造成日志累积。
1.1.3 每秒钟复制的操作数
在测试过程中，我们采用PL/SQL方式在源端产生1万,10万，100万条记录，以及进行1万,10万，100万的update,delete操作等。按照统计结果，DSG RealSync达到平均18000条/s的复制速度。完全能够满足单系统上用户IT系统的业务要求。
1.1.4 复制数据延迟
RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。
如果每天产生30GB的日志量，在155Mb带宽的情况下，可确保数据的延迟在5秒钟左右。
1.1.5 CPU资源占用
DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为<5%的CPU资源占用。
根据我们在河北地税的使用情况来看，在石家庄地市征管高峰期每2分钟产生100MB的日志量，而REALSYNC的日志分析资源占用仅为2%（4cpu,
1.1.6 源端的缓存空间
当容灾中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。
当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。
根据每天平均产生25GB的日志计算，我们建议在源端给REALSYNC预留的缓存空间能够满足一天的缓存量：按照1/3的比例计算并增加一定的富裕量，需予留10GB的缓存存储空间。
1.1.7 业务切换
RealSync是通过对Oracle Log日志进行分析获取跟踪源系统的交易指令实时的将指令传输到目标端进行加载，且目标端数据库始终在OPEN状态，可实时在目标端进行查询和统计，所以当灾难发生时或在主机源端发生故障以后，可直接将生产端数据库切换到容灾端，目标端数据库不需要重新启动，确保目标端数据的可用性，并大大提高了RTO、RPO指标。
1.1.8 RTO,RPO指标规划
采用交易级数据实时备份份技术，在RTO，RPO指标方面可以做到：
RPO指标取决于源端日志分析的频率、日志分析的效率、网络带宽和容灾端装载性能。
源端日志分析频率建议设置为1秒，即每间隔1秒中判断日志是否有新的变化。加上网络延迟和装载延迟，DSG Realsync一般将延迟能控制在3秒左右。但建议关键系统在制定RPO标准时可以适当的留出一定富裕量，建议设置为1分钟。
RTO指标牵涉到数据库接管时间、应用服务器的切换时间和终端的切换时间。
对于采用交易复制技术的解决方案来说，在发生故障切换时，容灾端的数据库本来就处于OPEN状态，所以不需要重新启动数据库，但是由于在正常复制过程，容灾数据库上的trigger是被disable的，所以在业务接管之前需要激活trigger，所需要的时间根据trigger的数量来定，一般可在10分钟以内完成。
至于应用服务器的切换时间和终端的切换时间与应用密切相关，这里无法给出一个具体的估计。
在采用了DSG的realsync加snapassure一体化备份解决方案后，可提供所有情况下的灾难恢复支持，包括业务连续性的切换，也包括因为误操作而造成的数据损坏。
1.2.1 本地和异地的数据实时备份
通过dsg realsync的实时复制功能，将数据实时备份到本地服务器上异地服务器上。
DSG realsync可以配置实时备份的时间间隔（日志抓取的频率），一般在证券行业我们建议设置为1~2秒。
这样本地服务器上的数据延迟一般可控制在3秒左右。异地备份服务器的延迟根据网络带宽的大小和数据量的大小一般延迟可控制在5秒左右。
1.2.2 本地数据定时备份
通过dsg snapassure的定时复制功能，将数据实时备份到本地备份服务器上。
DSG Snapassure的备份策略一般设置为：
l 每周六晚上进行一次全库的物理全备份；对于证券行业的数据量大小，一次物理全备的时间基本在30分钟左右；
l 每天晚上清算后作一次全库的增量备份；对于证券行业的数据量大小，一次全库的增量备份的时间基本在10分钟左右。
对于数据量在100GB以下的系统，建议每天都作全备份即可。
l 平常将archive log备份；
l 系统作升级、调整、测试前作一次物理全备份。
在备份服务器上一般建议保存2周以上的数据，这样当数据出现误操作丢失后，我们可以通过每天的备份版本和当天的archive log日志recover到出现故障前的时间点。
1.2.3 灾难恢复策略
在采用了实时备份和定时备份一体化保护的情况下，我们在出现灾难时选择哪种技术进行恢复，遵循以下几个原则：
如果是因为硬件的问题，例如服务器无法启动、磁盘阵列无法启动、或者网络不通等情况下，需要利用实时备份系统来接管业务。
如果是数据库的性能问题、或者数据库无法启动，这时需要利用实时备份系统来接管业务；
如果是因为人为误操作造成了数据破坏，比如TRUNCATE TABLE,DROP TABLE，等造成了数据的破坏，尤其是历史数据的破坏，这时后实时备份系统上的数据也是坏的，所以需要利用定时备份系统来恢复丢失的数据。 本文出自 51CTO.COM技术博客 |
gulibin
博客统计信息
热门文章
最新评论
友情链接
