System Replication-這一篇我們要專門講HANA最高等的高可用度Solution.

這一個Solution也不僅限於在不同的機房，如果夠有錢也可以在同一個機房實行。System Replication概念就是搞兩套一模一樣的軟硬體然後做同步的動作。下圖中若主要系統有standby host,在另一邊可以不用有standby host.

兩邊都要有同樣的SID及相同的設定，第二套系統可以是standby mode 或是read only mode.意思是同步過去的資料前端的程式可以讀取。另外在第二套系統上你也可以設定資料(pre-load)在Memory上面跑，如果是read-only mode大都是要將資料放在Memory上面。而它failover 的速度要比HOST failover快很多，所以你若是scale up的架構，哪麼在同一個地點你就可以使用System Replication當作你的備援系統。此外還有以下這些需要注意

1. 這個架構下每一個HANA的Service都"各自"將本身的資料同步到另一個系統去，這個Solution是同步整個HANA System 包含 system DB and tenant DB,無法特別同步其中一個DB。
2. 任何INI檔的系統設定在一邊異動後也需要同步在另一邊異動，不然你就會看到自動檢查configuration機制會發出告警。再來Secondary system的HANA版本要等於或高於Primary System. 但若是要在Secondary system啟用read-only mode,哪兩邊的版本就要一樣。
3. 當你create一個新的 tenant DB時一定要先做一次backup,否則system replication不會幫你在Primary system同步這一個tenant DB過去。
4. 當你要啟用system replication時需要將在Primary system 的PKI SSFS .key的檔案copy到secondary system ,路徑如下
   /usr/sap//SYS/global/security/rsecssfs/data/SSFS_.DAT/usr/sap//SYS/global/security/rsecssfs/key/SSFS_.KEY
   如果有安裝 XS advanced也要把這個key copy去到相對應的路徑。
   /usr/sap//SYS/global/xsa/security/ssfs/data/SSFS_.DAT/usr/sap//SYS/global/xsa/security/ssfs/key/SSFS_.KEY
   確認Primary system 與Secondary system底下的host name沒有相同，可以用landscapeHostConfiguration.py的Python腳本來檢查。|
   確認在Global.ini檔中的 log_mode參數是設定成normal的，這樣這些log才可以被備份。

上圖中，Primary system會確定Secondary system有收到 transaction log之後 commit 才會成功，確保不會有資料遺失。但假設你的secondary system fail了， Primary system會積累tramsaction log，所以若seconday system掛掉太久哪它可能就要花很久的時間才能把資料追到跟primary一樣，而且log存在primary system的空間可能也有限。所以需要特別注意這一點，比較好的方式是加入data snapshot非同步性的傳送資料。

System Replication Mode(log replication)
上面有提到 Primary system會把tansaction log確認傳送到Secondary system的memory中，資料庫的交易才算成功這個稱作 “Synchronous in memory ”.這種的效率比較好，因為不會使用到效能差的storage layer.但有資料遺失的風險，因為都放在Memory上面所以要搭配Operation mode,後面會提及。
另外兩種是
Synchronous on disk(with full sync -option):
這一個一樣是transaction log的傳送，但是是傳送到HD端。當兩邊斷線時，Primary system 會將log積累在自己的空間等到連線回復再繼續傳送。但若不幸primaty system 掛了資料就會遺失了。而這個模式還可以將Full sync選項開啟，這是是將Primary system在memory 的log buffer直接傳送到Secondary system,兩邊的log buffer一致且 transaction log都有被寫入到兩邊的系統交易才會成功。這一個方式會需要付出極高的網路效能與可用性，因為一旦網路斷線所有在Primary system的交易都會失敗。
Asynchronous:
這跟第一種不一樣的是，第一種Primary system確認收到log才會commit交易。但非同步是指primary system將transaction log送出後會部會確認定一邊有沒有收到commit就會成功，這種方式會有遺失資料的風險。

System Replication — Operation Mode
前面提到是transaction log的傳送模式，但傳送之後secondary system有兩種方式來處理log

1. Delta data shipping:(預設每10分鐘傳送一次)
   也就是log收到不會處理，等到recovery之後才開始replay這一些在primary system跑過的交易，這個在做災難復原是會很耗時間。 而同時也傳送在Memory 的Delta資料也耗網路資源，兩邊有差異就會再傳送一次。
2. LogReplay Mode:
   Secondary system在收到log之後就馬上replay Primary system的交易加上pre-load選項在做災難復原幾乎可以馬上在secondary system啟用服務。而且也不需要傳送Delta資料。
3. LogReplay Read Access
   這個選項如同上一個LogReplay mode,只是將primary system的read功能開啟，可以說兩邊的系統都處於Active/Active的狀態。
   

設定
我們可以從HANA Studio設定

接下來會是如下選擇

若是整個system DB還是online中，你就只有Enable system replication可以選，所以在secondary (target system)我們就需要把它關閉。

之後如上圖，就可以把這個停止服務的DB註冊成為Secondary system.並選擇 Replication mode and Operation Mode與跟soure sysem的主機資訊。

成功後你在Primary 與Secondary system的圖示會稍有不同(如下圖)

在Primary system點選進入後會看到更詳細的資訊