CDP是什么東東？與正常的備份有什么區(qū)別？

xiaophedap

冬瓜頭，你有個概念理解錯了，CDP才能更好的保證rpo，而不是snapshot。
不管是CDP還是snapshot，至少有一個概念它們是要用到了：一致性組

snapshot起作用，也只是對它屬下的一致性組里面的LUN來產生一個快照，CDP對IO的一致性保證，也是一樣。但snapshot相對CDP來說，一是顆粒度比較大，二來就是快照其實最開始就是指針——這表示什么你應該很清楚了。

而CDP對IO的一致性保證，正是通過對每一個寫IO打上了一個時間戳，在一致性組中對應LUN的寫IO，就通過了這些時間戳來嚴格保證可用性。

假使沒有帶寬之類的瓶頸，CDP回滾的顆粒度，可以達到毫秒的級別。至少在EMC RecoverPiont上的測試，我驗證過了。

xiaophedap

原帖由 jgtvisionnex 于 2009-10-30 16:25 發(fā)表
我可以這么理解嗎？連續(xù)的Snapshot是不是就可以理解為CDP呢？

如果Snapshot可以做到2秒一個的話，是不是就是CDP的概念！

現(xiàn)在有一款硬件產品好像可以做到1分鐘一個，他們把這個就叫做CDP！我不是很清楚， ...

snapshot產生的是指針，CDP是真實的數(shù)據(jù)拷貝。
如果你吧snapshot改成mirror，或者是clone，可以大致這么來看。

但還有一個最本質的不同就是，CDP同步的是IO，而基于存儲的clone，mirror，snapshot，同步的是“塊”，這決定了，在嚴格控制要回滾到什么時間點的數(shù)據(jù)，顆粒度上沒有CDP那么細致。

chnod

精辟，哥們看來對CDP了解頗深啊

xiaophedap

原帖由 冬瓜頭 于 2009-10-30 12:07 發(fā)表
如3樓，cdp只能通過犧牲rpo來達到一致性，隨便找個時間點恢復除非碰巧，一般是不一致的。所以需要一些回滾手段，如6樓說的RP中就是利用日志來回滾到上一個commit point處。至于是否需要安裝主機agent來感知并控 ...

除非在每次做snapshot的時候，對數(shù)據(jù)庫做一次alter backup的操作，否則做出來的snapshot，10次基本上有5--7次（根據(jù)應用的繁忙程度），也是需要做數(shù)據(jù)庫回滾的。
因此，回滾和不回滾，是基于數(shù)據(jù)庫的要求。而不是snapshot或者是CDP。

冬瓜頭

我沒說過snapshot比cdp的rpo小，我只說過cdp的rpo在底層看似是0，但是對于上層一定是大于等于0，因為需要回滾，靠cdp自己的日志回滾也好，或者干脆靠應用層回滾也好。
另外，關于snapshot一致性是分層的，文件系統(tǒng)及其下層，還有應用層，前者做的snapshot至少在文件系統(tǒng)層是一致的，但是不一定應用層一致，后者則可以保證應用層一致，xiaophedap測試過RP也應該知道RP是有應用層agent來同步應用的commit point然后標記在日志中的，所以才能做到日志回滾。

還有，cdp得根據(jù)實現(xiàn)方式來判斷是否是“真實的數(shù)據(jù)拷貝”。對于RP或者Ipstor CDP這種鏡像數(shù)據(jù)之后在鏡像中做cdp，當然是拷貝了。如果其他實現(xiàn)方式比如直接在線實現(xiàn)或者使用附加的block倉庫方式，那也需要指針。

為什么刪我號

CDP就是不間斷時間數(shù)據(jù)的備份和存儲

wyddg

原帖由 xiaophedap 于 2009-10-30 21:53 發(fā)表
冬瓜頭，你有個概念理解錯了，CDP才能更好的保證rpo，而不是snapshot。
不管是CDP還是snapshot，至少有一個概念它們是要用到了：一致性組

snapshot起作用，也只是對它屬下的一致性組里面的LUN來產生一個快照 ...

CDP和snapshot根本不是一個概念，你所謂的CDP技術同步的是IO，請問是什么IO？ 文件系統(tǒng)IO？ 應用程序IO？

按照你舉的例子，EMC RecoverPoint，我想同步的應該是磁盤陣列IO，但是CDP的作用是將業(yè)務應用恢復到非常近甚至接近0的

時間點，你記錄的磁盤陣列的IO的CDP只能將磁盤陣列狀態(tài)恢復，根本無法保證應用的一致性，這個時候才往往采用快照等手段，

在記錄IO的過程中通過應用的agent  think 臟數(shù)據(jù)或者調整應用狀態(tài)到備份模式等等找尋應用的一致性點，

即對客戶來說，這些一致性點的數(shù)據(jù)才是可靠性，可用的。

所以基于磁盤陣列等硬件設備的CDP，包括飛康的、EMC的，都是扯淡！這類底層IO同步的CDP實現(xiàn)方式恢復的都是一致性點的數(shù)

據(jù)，根本不可能做到CDP，如果強行恢復非一致性點數(shù)據(jù)，就會造成業(yè)務無法啟動，或者數(shù)據(jù)部分丟失！針對應用CDP的高端客戶

來說，這根本無法接受！

要做到真正意義的CDP，必須從應用出發(fā)，要靠應用本身，

例如Oracle這些應用通過自身手段，在應用端實現(xiàn)才有可能出現(xiàn)真正的CDP！

[ 本帖最后由 wyddg 于 2009-10-31 10:20 編輯 ]

冬瓜頭

“所以基于磁盤陣列等硬件設備的CDP，包括飛康的、EMC的，都是扯淡！”
底層只能是先保持在線存儲的同步鏡像，至于是否一致，這個又繞回來了，兩個一致性層次：文件系統(tǒng)及其下層，應用自身的buffer一致性和邏輯一致性，只有應用的邏輯一致性才是端到端的一致性，也是追求的最終目標。通過底層實現(xiàn)的cdp可以靠上層回滾來實現(xiàn)一致性，而如果從應用層來實現(xiàn)cdp，比如oracle dataguard，可以看做是一種cdp，它也一樣需要應用replay。所以底層cdp和上層cdp，本質是一樣的，不是扯淡。

wyddg

原帖由 冬瓜頭 于 2009-10-31 10:33 發(fā)表
“所以基于磁盤陣列等硬件設備的CDP，包括飛康的、EMC的，都是扯淡！”
底層只能是先保持在線存儲的同步鏡像，至于是否一致，這個又繞回來了，兩個一致性層次：文件系統(tǒng)及其下層，應用自身的buffer一致性和邏輯 ...

CDP的目的是保護業(yè)務和應用，你也說了要保證應用的邏輯一致性才是目標，底層IO不可能保證這一點，必須與邏輯應用通信耦

合，通過上層邏輯應用來保證底層IO的一致性，think 內存、調整應用到備份狀態(tài)等等手段，耽誤很多時間，而且這些操作對業(yè)務

應用的運行和性能都有不少影響，不可能做的非常頻繁！

這也導致不可能做到真正意義上的CDP對RPO的要求（接近于0），所以說那是扯淡！

而Data Guard你提到的只是物理方式的異步模式，目前Data Guard在9i之后（10gr2之后就已經用的很多了）的邏輯同步模式，

就能保證事務和SQL的同步，或者現(xiàn)在Oracle在10g/11g用的非常多的Streams，11g之后Streams支持實時的數(shù)據(jù)捕獲，以及

業(yè)界專門針對Oracle應用開發(fā)的一些技術Quest的share plex（eBay采用的方式，Streams與其原理相近）等等，都根本不需要

你所說的Reply，這些才是有可能真正實現(xiàn)CDP（業(yè)務應用的RPO接近于0）的方式！

[ 本帖最后由 wyddg 于 2009-10-31 11:04 編輯 ]

為什么刪我號