CDP是什么东东？与正常的备份有什么区别？

xiaophedap

原帖由 wyddg 于 2009-11-4 18:52 发表



不是数据库自己做不到，只是你不知道而已，

前面我和冬瓜头已经说过了数据库实现CDP的最小粒度是事务，而不是什么时间点，时间点对数据库来说意义不大，

Data Guard逻辑同步模式、Streams、DSG re ...

看来你也没明白我帖子里面的意思。

事务，需要写IO不？需要写IO就会被CDP同步。
灾难发生了，数据库能100%（即每一次都能）恢复到最后传的一个事务，而不需要reply么？需要，那和CDP最后一个IO同步过去，仍然需要回滚一下有什么本质区别呢？

CDP，就是时间戳同步每一个写IO。

除非，你告诉我事务不需要写IO了。那我没啥可说的。

wyddg

原帖由 xiaophedap 于 2009-11-4 19:15 发表


看来你也没明白我帖子里面的意思。

事务，需要写IO不？需要写IO就会被CDP同步。
灾难发生了，数据库能100%（即每一次都能）恢复到最后传的一个事务，而不需要reply么？需要，那和CDP最后一个IO同步过去 ...

数据库CDP最小粒度是事务 基于应用的方式就是基于逻辑层按照事务粒度进行同步的，

你的底层IO如何转化为数据库事务？

CDP不光是恢复到最近的时间点，是可以恢复到粒度很小的时间点（数据库就是事务粒度），

按照应用可以按照事务回滚到以前的很多数据库一致的时间点，因为我本来就是按照事务进行同步的，

你同步的是底层IO，有谁知道上一个事务应该回滚到什么时候？所以你恢复的是专门的一致性点，而不是任意IO记录点，

配合客户端的agent实现的，而这样的一致性点不可能时间间隔很小的去做，所以我觉得底层的CDP有点挂羊头卖狗肉之嫌。


这个问题不再讨论了

[ 本帖最后由 wyddg 于 2009-11-5 09:24 编辑 ]

冬瓜头

恕我再说一句。我感觉wyddg的这句话有问题，也是最终导致矛盾的地方。“有谁知道上一个事务应该回滚到什么时候”，当然是应用知道，这一点正如之前帖子说的，根本不用关心。

wyddg

原帖由 冬瓜头 于 2009-11-5 09:33 发表
恕我再说一句。我感觉wyddg的这句话有问题，也是最终导致矛盾的地方。“有谁知道上一个事务应该回滚到什么时候”，当然是应用知道，这一点正如之前帖子说的，根本不用关心。

呵呵 这是我们争论的关键点吧 恕我再说1句

1、这种不一致的状态完全靠应用去做你说的replay具有较大的风险，可能根本起不来应用

2、即时能启动应用也要花费很多时间，就像文件系统的fsck。。。。。。

使用CDP的高端客户能够接受以上2种情况吗？

就是以上2种原因导致底层IO的CDP都是去恢复的一致性点（通过快照等等），而不是照你说的那样随便恢复一个IO时间点，

再去Replay（请尽量看看实际项目中客户怎么操作的，厂家是怎么推荐的，是恢复一致性点还是任意IO点再去Repaly），

底层CDP通常是恢复一致性点，但是一致性点不能间隔很小，我就觉得在实际使用中的根本不是CDP的本质，只是一种备份

恢复方法而已。

基于应用层的回滚都是基于逻辑事务的，不存在上面的问题，我的意思是真正的CDP还得基于应用来搞。

冬瓜头

这样说吧，突然down机你能不能接受？我的意思是突发原因，而不是人为的去给关掉，你能接受有这样的事件发生，那就能接受底层cdp，因为底层cdp和源的状态是一样的。down机后源起不来的话，cdp不见得起不来，因为可以往前滚一下再起然后上层replay。现在fs几乎都是日志型，不需要很多时间恢复。我想突出的是，上层的cdp和底层的本质一样。

xzcsiwh

原帖由 wyddg 于 2009-11-5 09:45 发表


呵呵 这是我们争论的关键点吧 恕我再说1句

1、这种不一致的状态完全靠应用去做你说的replay具有较大的风险，可能根本起不来应用

2、即时能启动应用也要花费很多时间，就像文件系统的fsck。。。。。。 ...

CDP 是从存储层面提供的一种解决途径， 若应用层软件出问题，可以从存储层解决。 不要把鸡蛋都放到一个篮子里

xzcsiwh

应用是个很广的概念， 举个例子  array -> OS(VM) -> disk Database -> memory Database - > midlleware -> webserver  ....  每一层都有持续业务保护的功能（在array 叫 CDP）， 只是名字或实现方式不一样。

xiaophedap

原帖由 冬瓜头 于 2009-11-5 10:10 发表
这样说吧，突然down机你能不能接受？我的意思是突发原因，而不是人为的去给关掉，你能接受有这样的事件发生，那就能接受底层cdp，因为底层cdp和源的状态是一样的。down机后源起不来的话，cdp不见得起不来，因为 ...

最后一句话就是关键：CDP和上层保证一致性的本质是一样的。

这就是我解释的那么多，为啥CDP要多每一个IO有一个时间戳。

我绝对也不相信在系统突然掉电的时候，上层应用能严格（即每一次）保证最后一个事务（或者倒数第二个事务）可以100%恢复。换句话说，RPO只能尽可能趋近于0，而不可能=0。
如果说做快照能满足，其实CDP就可以看成是小维度的连续快照（之前我也解释了CDP和传统快照比较之下的优势）。

事务和CDP比较起来，最大的优势在于，不实在这种很糟糕的情况下，恢复的时间点确实比CDP更有优势（更接近最后一个事务）。不过这要以牺牲性能为代价。

我承认，最完美的容灾应该从应用着手，写完本地事务，并同步到远端，反馈完成以后，应用才开始下一个事务。这样的机制下，才是完美无缺的容灾。

不过容灾的目的，真的是保证完美无缺吗？
至少我认为不是这样。在多次和客户的交流中，我一再表示的观点就是：容灾的目的是保证RPO、RTO能满足业务连续性的要求即可。最求完美，意味着投资。

冬瓜头

在应用程序显示的commit，以及底层完全同步的情况下，数据理论上是不丢失的，redo和undo不代表丢失数据，这样的话，rpo=0。但是你要说不是每次都能起来，这就是另外一回事了。

wyddg

原帖由 xiaophedap 于 2009-11-5 16:23 发表


最后一句话就是关键：CDP和上层保证一致性的本质是一样的。

这就是我解释的那么多，为啥CDP要多每一个IO有一个时间戳。

我绝对也不相信在系统突然掉电的时候，上层应用能严格（即每一次）保证最后一个 ...

其实你和冬瓜头解释了很多，但是需要明确的是，在实际的客户应用环境中，

客户是否采用了你们所说的那种方式，底层CDP的实现厂商都开发了客户端代理，保证指定时间点的数据一致性，EMC也不例外，

据我了解客户使用底层CDP都是去恢复一致性点，而不是去恢复任意时间戳的IO，

这也是厂商推荐度的方式，这也是厂商去开发CDP客户端代理的原因，如果按照你们的说法，厂商只需要客户端的

spliter，根本不需要保证应用一致性的客户端代理程序了。。。。。。