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

chnod

我看也是，太技术化了，为什么就没有想怎么应用呢？

wyddg

原帖由 andy_lyb 于 2009-11-2 09:48 发表
二位达人，兄弟掺合一下哦。

我想二位可能忽略了一点，CDP为什么只有在存储这个板块里被讨论？（或者是兄弟寡闻，不知道在应用方面有没有类似的说法）

就好比冬瓜兄说过的一句：如果服务器突然Down机了， ...

兄弟说的在理，我并没有否定底层存储的CDP实现方式，

我只是觉得底层的CDP实现方式，根本保证不了需要CDP应用的很低的RPO需求，要不就存在风险和需要大量的时间，

为什么前面我已经说了很多次了，

这些方法都是很好的数据保护的方式（很多融合了备份和容灾），但是称自己是CDP，感觉挺别扭的

xiaophedap

原帖由 冬瓜头 于 2009-10-31 18:57 发表
你我正好反过来了，底层的每一个写io都被镜像的话，当然也就镜像了每一笔transaction，至于最后的一致性点在哪里，这个不用关心，只要每一个写io都保存了，还怕什么？replay一下恢复到最后的一致点就好了。这一 ...

这个说法是正确的。

to wyddg：
不管是通过应用本身CDP也好，还是通过飞康EMC CDP也好，总的来说，都是通过IO的次序来保证一致性的。
也就是说，从上层应用来说，你的任何事务通过自己来CDP，首先是这个事务需要commit，而如果有了写IO的这个动作，这个应用的IO是写到什么地方去？毫无疑问是存储。
对于应用的CDP来说，就是保证备份数据IO的次序和本地事务commit的次序是一样的，甚至时间戳也是一样的。

上面既然说了IO是要写到存储的，那么对于存储CDP的做法来说，就有三种方式将应用的事务和存储IO关联起来：
1. 基于主机的splitter
2. 基于交换机的splitter
3. 基于存储的splitter
而不管以上三种何种做法，都是对写IO打上了一个时间戳，这个时间戳本身就对应数据库的事务。

不知道这样说，是否能够解释你对CDP的和事务关联之间的疑问。

而CDP和普通的snapshot，clone，mirror，比较起来，其优势在于：
1. snapshot只是指针，而且是某一个时间点的指针
2. clone虽然是数据，但也是某个时间点的数据
3. mirror虽然是实时同步，但如果源数据出现逻辑错误，备份数据也同样会有这个错误。因此，mirror常常和snapshot，或者clone结合起来使用。但总不能每一秒或者每过几秒就产生一个snapshot吧？
4. CDP可以根据需要，将数据回滚到甚至1秒之前，几分钟之前，几小时之前，几天之前，甚至1个星期或者1个月之前
5. 因为和应用的事务有我之前说的那种内联的关系，因此，只要CDP的应用服务器和业务应用服务器之间配置了NTP，那么可以完全保证回滚的数据到某个时间点（当然不是精确控制的，应用CDP本身自己也无法做到精确的，是不？）

但CDP和传统的snapshot，clone，mirror比较起来，也有它自己不太擅长的地方。

chnod

又学到很多东西，谢谢~~~

wyddg

原帖由 xiaophedap 于 2009-11-2 19:21 发表


这个说法是正确的。

to wyddg：
不管是通过应用本身CDP也好，还是通过飞康EMC CDP也好，总的来说，都是通过IO的次序来保证一致性的。
也就是说，从上层应用来说，你的任何事务通过自己来CDP，首先是这 ...

1. 基于主机的splitter
2. 基于交换机的splitter
3. 基于存储的splitter
而不管以上三种何种做法，都是对写IO打上了一个时间戳，这个时间戳本身就对应数据库的事务


瞎扯。。。。。。

[ 本帖最后由 wyddg 于 2009-11-3 16:46 编辑 ]

xiaophedap

原帖由 wyddg 于 2009-11-3 16:44 发表



1. 基于主机的splitter
2. 基于交换机的splitter
3. 基于存储的splitter
而不管以上三种何种做法，都是对写IO打上了一个时间戳，这个时间戳本身就对应数据库的事务


瞎扯。。。。。。

既然你认为这是瞎扯，那就没有继续讨论的必要了。

我相信实施过CDP的兄弟都应该知道CDP的原理。顺带做个广告，至少我实施的EMC RecoverPiont是这样，要恢复到那个时间点，就能恢复到哪个时间点

wyddg

原帖由 xiaophedap 于 2009-11-3 21:12 发表


既然你认为这是瞎扯，那就没有继续讨论的必要了。

我相信实施过CDP的兄弟都应该知道CDP的原理。顺带做个广告，至少我实施的EMC RecoverPiont是这样，要恢复到那个时间点，就能恢复到哪个时间点

1. 基于主机的splitter
2. 基于交换机的splitter
3. 基于存储的splitter
而不管以上三种何种做法，都是对写IO打上了一个时间戳，这个时间戳本身就对应数据库的事务


不是我说你瞎扯，你问问冬瓜头和其他人你上面的理论是不是瞎扯。。。。。。

你的EMC RecoverPoint恢复的不过是磁盘阵列的时间点，对客户的上层应用根本没有意义

冬瓜头

我想xiaophedap的意思是说底层可以恢复到任何时间点（随便指定而不是由软件指定的consistent point），但是上层不可能直接就基于这个时间点的镜像起来了而且不做任何redoundo。

xiaophedap

原帖由 冬瓜头 于 2009-11-4 10:43 发表
我想xiaophedap的意思是说底层可以恢复到任何时间点（随便指定而不是由软件指定的consistent point），但是上层不可能直接就基于这个时间点的镜像起来了而且不做任何redoundo。

我之前想表达的意思是，其实在CDP中，通过对写IO打上时间戳这个动作，也就将底层的数据同步和上层应用写IO次序之间关联了起来。这个关联是一个很重要的东西，它意味着上层数据库能恢复到某个时间点，通过redoundo，那么我下层的数据也能同样回到那个时间点。
而打上时间戳的这个动作，可以通过三个方面来做到：
1. 主机的splitter
2. 交换机的splitter
3. 存储的splitter
这个splitter的作用，其实就是将任何一个写IO先copy一份，其中一份还是如原来的，直接写入到存储，另外一份则打上时间戳，同步到对端。这样在CDP的容灾方案里面，和原来基于纯存储的同步，就有了一个本质的飞跃。因为我们可以控制将数据回滚到需要的时间点。



其实冬瓜头在这里说的也是对的。这就是为什么我最开始就说了，这类CDP能确保我数据回滚到哪个时间点，但无法精确指定数据库就是从这个时间点来打开的——因为数据库自己都无法做到这一点，除非不断在backup mode和正常模式之间来回切换——但来回切换不是一样不能保证“完全精确”的时间点么？
如果数据库自己都不能做到“完全精确”，而只能是“尽可能精确到那个时间点”，那么CDP能做到的也不过是“尽可能精确到那个时间点”。

wyddg

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



我之前想表达的意思是，其实在CDP中，通过对写IO打上时间戳这个动作，也就将底层的数据同步和上层应用写IO次序之间关联了起来。这个关联是一个很重要的东西，它意味着上层数据库能恢复到某个时间点，通过 ...

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

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

Data Guard逻辑同步模式、Streams、DSG realsyc、Quest share plex都可以实现基于逻辑层的
事务同步，根本不需要调整数据库的状态

建议你在发表意见之前，仔细看看以前的回帖