基于陣列的復制，oracle之類的數(shù)據(jù)庫能保證同步么

forecast777

原帖由 無牙 于 2009-6-4 11:16 發(fā)表
如果VVR SRL寫滿，啟用了DCM，也是能保證一致性的。
數(shù)據(jù)復制后是不是能用，和數(shù)據(jù)庫本身的機理有關(guān)系，這時候就要靠數(shù)據(jù)庫的日志來前滾或者后滾。

謝謝！

陣列的time stamp也是一個卷么？如果寫滿寫bitmap也不能保障一致性吧？

time stamp和veritas Log機制有優(yōu)缺點的不同么？？

mmmmn

原帖由 bbjmmj 于 2009-6-2 15:54 發(fā)表
存儲復制最要命的就是通信中斷，無論同步復制還是異步復制，都存在這個風險，災(zāi)備線路一旦中斷，業(yè)務(wù)就要停止，雖然可以用MULTIPATH、路由之類的輔助手段加以預防，但并沒有徹底解決業(yè)務(wù)中斷的問題，比如災(zāi)備中心發(fā)生火災(zāi)，或者設(shè)備故障，那業(yè)務(wù)就不可避免地要中斷

不明白

ffaatt

我是做售前的，對技術(shù)細節(jié)沒有深入了解，以下觀點未必正確，請大家指正。
1.基于陣列的同步模式遠程復制是能夠保證數(shù)據(jù)一致性的，至于數(shù)據(jù)是在陣列Cache還是寫入了Disk沒有什么關(guān)系；在數(shù)據(jù)庫Cache中的數(shù)據(jù)不一致是由數(shù)據(jù)庫自己的log機制負責的，和陣列沒有關(guān)系；
2.在異步模式下比較復雜
   1).異步模式丟數(shù)據(jù)很正常，但是需要保證2個事情，a.鏈路中斷后已傳輸?shù)臄?shù)據(jù)始終是一致的，b.鏈路恢復后續(xù)傳的數(shù)據(jù)也是一致的（當鏈路再次中斷仍然能夠保持正確）
   2)大多數(shù)陣列異步模式的實現(xiàn)方法：在Cache中建立IO隊列（可能有timestamp），在多個磁盤卷之間建立一致性組（包括數(shù)據(jù)庫的數(shù)據(jù)文件、日志文件等），這樣基本都能滿足a.的需求
   3)問題是陣列Cache大小有限，當鏈路速度太慢或者長時間中斷時，Cache隊列溢出了，有些陣列只能放棄復制，等鏈路恢復后重新來過（所有源數(shù)據(jù)再拷貝一次），有些陣列放棄隊列模式，改用Bitmap模式，在鏈路恢復后先按照Bitmap復制，完成后再回到正常的隊列模式，這兩種陣列都不能滿足b.的需求。在容災(zāi)系統(tǒng)規(guī)劃中就是“二次容災(zāi)問題”，當?shù)谝淮螢?zāi)難結(jié)束/鏈路恢復后，如果在數(shù)據(jù)沒有完全同步時再來一次災(zāi)難，那么遠端數(shù)據(jù)就是不一致的，容災(zāi)就白做了(僅指陣列層面)，所以在第一次鏈路恢復后，不能立刻同步數(shù)據(jù)，而是先把遠端的數(shù)據(jù)做一個本地復制(Shadowimage之類)，然后再同步，即使再次發(fā)生災(zāi)難，至少遠端還有一份老一點的數(shù)據(jù)。關(guān)鍵它是"一致的"，可以用來恢復應(yīng)用；
  4)在高端磁盤陣列中(其實真正的高端也就HDS USP和EMC，加HP OEM的XP),USP/XP有3種復制模式：“同步”，“異步”，“日志異步”。日志異步就是在陣列中專門配置一個RAID組用于存放IO日志(帶Timestamp)，這樣在鏈路中斷時可以繼續(xù)記錄IO隊列(RAID組可以保存TB級的數(shù)據(jù)，Cache是GB級的)，因此可以滿足b.的需求。還有一些其他的好處，日志異步方式是由遠端主動到本地讀取日志的“拉”模式，而不是本地發(fā)送到遠端的“推”模式，這樣本地陣列在復制中始終是被動的，負載較小，而且鏈路中斷時也不需要操心，鏈路恢復后由遠端來“拉”即可；另外日志模式可以容易實現(xiàn)1點對多點的容災(zāi)，1個本地陣列可以復制到多臺遠端陣列
  5)在中端陣列中(EMC CX, HP EVA, IBM/SUN/ DS, Netapp FAS)，我只知道EVA的異步復制是日志模式的，稱作"WHL"(Write History Log)，因為EVA的磁盤空間是劃分是自動分配的，所以陣列上沒有專門的日志盤，所有空閑的磁盤空間都可以拿來做日志，無需管理員干預，所以EVA基本也可以滿足二次容災(zāi)的需求。
  6)綜上所述，異步有“Cache隊列Timestamp+磁盤Bitmap”，“磁盤寫日志”2中模式，后面一種可以始終保持數(shù)據(jù)一致性

3.順便說句和存儲無關(guān)的題外話
   在容災(zāi)中要求保證一致性其實有很多層面的方法，陣列是其中一個層次，還需要其它層面的配合
   1)業(yè)務(wù)流程，例如每個業(yè)務(wù)操作都留有憑證，即使數(shù)據(jù)庫中丟了數(shù)據(jù)也能再輸進去
   2)應(yīng)用軟件，在寫數(shù)據(jù)庫之前先做一個log并傳到異地
   3)數(shù)據(jù)庫、操作系統(tǒng)/文件系統(tǒng)層面的日志/回滾技術(shù)
   4)最低層，最簡單的是陣列復制層面的

[ 本帖最后由 ffaatt 于 2009-6-4 18:46 編輯 ]

jadge

看大家都是在討論Oracle數(shù)據(jù)庫，其他哪些數(shù)據(jù)庫也可以與這個原理差不多呢？望各位賜教...不勝感謝

ffaatt

各種主流的數(shù)據(jù)庫產(chǎn)品一般都有日志、回滾這一套，還有類似的應(yīng)用如Exchange、Domino等也差不多。主流的陣列廠商（包括Veritas這樣的存儲軟件商）一般都會把自己的本地復制和和異地復制和這些應(yīng)用集成起來，有些做為實施服務(wù)來賣，有些免費給個腳本模板，還有一些打包成為一個產(chǎn)品模塊來賣，

wolfop

原帖由 forecast777 于 2009-6-4 11:32 發(fā)表
陣列如何能夠保障復制時的一致性呢？
如果redo log都有問題了，如何前滾或者后滾

你本地的redo log如果都有問題了，你如何前滾或者回滾？

forecast777

原帖由 wolfop 于 2009-6-4 20:09 發(fā)表

你本地的redo log如果都有問題了，你如何前滾或者回滾？

呵呵，我那個是反問句。
贊成“ffaatt“等人的觀點。

forecast777

原帖由 ffaatt 于 2009-6-4 17:56 發(fā)表
我是做售前的，對技術(shù)細節(jié)沒有深入了解，以下觀點未必正確，請大家指正。
1.基于陣列的同步模式遠程復制是能夠保證數(shù)據(jù)一致性的，至于數(shù)據(jù)是在陣列Cache還是寫入了Disk沒有什么關(guān)系；在數(shù)據(jù)庫Cache中的數(shù)據(jù)不一 ...

有兩個疑問請您指點：
1）Time stamp各廠商都在內(nèi)存實現(xiàn)么？ 有沒有把它放在一個獨立卷中的？  是否存在一個所需cache大小和帶寬、數(shù)據(jù)量/頻繁度等指標的對應(yīng)關(guān)系公式？

2）您說“所以在第一次鏈路恢復后，不能立刻同步數(shù)據(jù)，而是先把遠端的數(shù)據(jù)做一個本地復制(Shadowimage之類)，然后再同步” 這個是通過腳本實現(xiàn)么？  在push模式下，這個腳本觸發(fā)問題如何把握？？
另外某客戶案例是在備援站點每隔一個時間做個SI，這樣實現(xiàn)一致性和其它數(shù)據(jù)使用用途。 這個是最佳方法么？

[ 本帖最后由 forecast777 于 2009-6-4 21:15 編輯 ]

xiaomao2006

很好的題目,順便問一下,oracle的數(shù)據(jù)盤或文件用snapshot做備份,不管哪個廠商的,能從snapshot恢復嗎,我認為能,問題是數(shù)據(jù)會損失多少?

bbjmmj

感覺樓上FFAATT對存儲復制的說法已經(jīng)比較權(quán)威了。
說說我的看法，我不贊成使用存儲復制。
一方面是存儲復制太耗費帶寬，比如更改表中一個記錄中某個字段的值，這個操作，至少會影響到存儲數(shù)據(jù)庫文件的存儲系統(tǒng)的一個數(shù)據(jù)塊，同時還會影響日志文件，也就是說，即使我只是該了某個記錄中一個整形字段的值，使用存儲復制都要至少復制兩個以上的數(shù)據(jù)塊，實際數(shù)據(jù)發(fā)生更改的部分可能遠遠小于塊的尺寸，這個時候就存在帶寬嚴重浪費的情況。
另一方面，如果遠端沒有來得及“拉”塊，主存儲即發(fā)生了損壞，這個時候，不但要丟數(shù)據(jù)，甚至有可能破壞文件系統(tǒng)，這個問題比數(shù)據(jù)庫本身提供的REDO LOG要嚴重得多，REDO LOG只是丟掉一個操作，不存在破壞文件系統(tǒng)的問題。