« IMP-00009 abnormal end of export file | Blog首页 | 2009云计算大会 与 歌剧《图兰朵》 »
HDS Truecopy实现原理及项目的选择
链接：https://www.eygle.com/archives/2009/05/hds_truecopy_dataguard.html
这几天因为一个项目的需要，粗略研究了一下HDS Truecopy同步机制的实现。
TrueCopy是HDS基于硬件的同步解决方案，其实现与IBM公司的PPRC和EMC公司的SRDF类似，基于存储的同步复制没什么好说的，大家的实现都是几乎相同的，不过同步复制对于带宽、网络的要求都很高，在实践中的风险过高，所以采用有限，HDS的相应解决方案有三数据中心的中转解决机制，类似Oracle DataGuard的Cascade Redo传输机制，通过中转消除网络不稳定性可能带来的影响。
至于异步同步机制，如何保证数据的写顺序，如何保证数据库复制后能够被一致的打开成了一个问题。
下面一段文字说明了TrueCopy的实现原理，也就是通过时间戳和标志位来保证写顺序：
TrueCopy异步使用可靠的时间戳以及主系统生成的其他信息来使Freedom Storage能够把更新信息直接传送到次级系统(不需要主机的任何干预)。然后，次级系统在其缓冲区内缓冲、排队和按照时间戳对这些写内容排序，再以相同的序列将其写到相应的卷上。这些重写内容是由主系统通过记录内嵌的远程链路检查序列号发布的，以保证没有丢失任何记录，这样就保持了I/O的一致性。
下图是实现的原理图：
按照这个原理结构，如果存储级别能够很好的解决写序列的问题，复制环境的数据库是能够保证其一致性，顺利在灾难时完成打开恢复的。
在网上看到，湖南省公民身份认证查询系统（汇集湖南省6500万人口信息，并向社会提供身份认证、查询、挂失服务），是此系统的HDS 9200 True Copy数据同步方案为亚洲第一个成功的HDS 9200 TrueCopy数据同步方案，该项目是2002年左右实施的。
下图是该系统的架构图：
按照我们现在的审视，如果只着眼于数据库层面的同步，那么在短距离有光纤链路情况下，还是有多种低成本的方案可选的。
不知道有哪些朋友有用过TrueCopy同步的经验？
-The End-
历史上的今天...
>> 2016-05-20文章:
>> 2011-05-20文章:
>> 2010-05-20文章:
>> 2008-05-20文章:
>> 2006-05-20文章:
By eygle on 2009-05-20 10:34 | Comments (8) | Advanced | 2291 |
其实这些东西主要就是成本高，容易上套，将来两端存储都离不开一个厂家。
如果短距离可以做fc传输，将一份redo log file member放到远程也可以的，比复制还节约带宽。
最实惠的是 lgwr async传输。
最便宜的，还是tape。赫赫。
做过300强的企业，也是tape+"shared DR site"，就是说不是自己的DR,遇到的时候，才被分配资源。(downtime 24 hours allowed)
很好。。我先看看我占的是沙发不
整套方案只有有钱的企事业单位会用，毕竟烧钱。找到最合适自己的解决方案算是正道。在业界，究竟又多少种方案来实现这种同步机制？
原理图看不清楚，我晕。。。。
在国内使用TC做容灾的还是很多的，尤其是高端设备。
另外，在异步的情况下，HDS目前多推荐使用HUR（Hitachi Universal Replicator）。
在IBM的大型机与HDS设备配合的时候，用TC的很多，HDS几乎每次高端产品更新，第一个认证的几乎必然是IBM的主机，包括小机和Mainframe。
确实当时没有觉得做这个有什么难度，现在居然还能拿出来讲
楼上参与过这个项目？