MySQL Replication和Oracle logical standby的原理對比

        MySQL Replication和Oracle logical standby都是SQL apply，那麼在實現上有何區別？
       
        Binary Log 和 Redo的傳輸原理
       
        MySQL Replication可以很方便的用來做應用的讀擴充，也可以幫MySQL實現一定程度的HA方案
        整個複製過程實際上就是Slave從Master端抓取Binary Log然後再在自己身上完全順序的執行日誌中所記錄的各種操作

 

        ㈠ 如何同步？
      
           主庫將所有的更新操作，寫入二進位日誌。
           從庫運行"IO線程"（Slave IO Thread）讀取主庫的二進位日誌。
           從庫運行"SQL線程"（Slave SQL Thread）執行IO線程（Slave IO Thread）讀取的日誌中的SQL,從而保持和主庫的事務一致
      
        ㈡ 如何分配請求？
      
           目前，這部分需要在應用程式層實現。
           執行更新SQL(UPDATE，INSERT，DELETE)時，請求主庫
           執行查詢SQL(SELECT)時，請求從庫
           所以，當你的應用(Application)SELECT請求所佔的比率越大，那麼Relication就會越有效
      
       
        ㈢ MySQL如何傳輸二進位日誌，是主庫推，還是備庫拉？MySQL日誌傳輸的即時性如何？
       
        在MySQL Replication結構中，備庫端初次通過CHANGE MASTER TO完成Replication配置，再使用start slave命令開始複製
        更細緻的：
          ① Slave上的IO Thread串連上Master，並向Master發起讀取Binary Log的請求（COM_BINLOG_DUMP命令），
             從指定記錄檔的指定位置（或者最開始的日誌）之後的日誌內容
          ② Master收到COM_BINLOG_DUMP請求後，使用dump thread不斷向Slave IO Thread發送Binary Log（指定記錄檔的指定位置之後的日誌資訊）
             返回資訊中除了日誌所包含的資訊之外，還包括本次返回的資訊在Master的Binary Log的檔案名稱以及在Binary Log中的位置
          ③ 在Master一旦有新的日誌產生後，立刻會發送一次廣播，dump thread在收到廣播後，則會讀取二進位日誌並通過網路向Slave傳輸日誌
          ④ Slave的IO thread接收到資訊後，將接收到的日誌內容依次寫入到Slave的Relay Log檔案（mysql-relay-bin.xxxxxx)的最末端。並將讀取到的
             Master的Binary Log的檔案名稱和位置記錄到master-info檔案中，以便在下次讀取的時候能夠清楚地告訴Master：
             “俺們需要從某個Binary Log的哪個位置開始往後的日誌內容，請發給我”
          ⑤ Slave的SQL thread檢測到Relay Log中新增加了內容後，會馬上解析Log檔案中的內容成為在Master真實執行時候的那些可執行檔Query語句，
             並在自身執行這些Query。這樣，實際上就是在Master和Slave執行了同樣的Query，所以兩端的資料完全一樣。
          所以這是一個主庫向備庫不斷推送的過程

        新日誌在產生後，只需一次廣播和網路就會立刻（<1ms）向發送到備庫，如果主備之間網路較好的話（例如RTT<1ms），備庫端的日誌也就小於2ms了
        所以，一般的（依賴於RTT），備庫的即時性都非常好。
        注釋：
        RTT(Round-Trip Time): 往返時延，在電腦網路中它也是一個重要的效能指標，
        它表示從發送端發送資料開始，到發送端收到來自接收端的確認（接收端收到資料後便立即發送確認），總共經曆的時延
       
       
       
        對於Oracle，在primary，DataGuard可以使用歸檔進程(ARCn)或者日誌寫進程(LGWR)收集redo資料並傳輸到standby
       
        ㈠ 使用ARCn歸檔redo資料
           預設情況下，RTS使用ARCn進程歸檔redo日誌。不過ARCn歸檔進程只支援最高效能的保護模式
           primary日誌發生切換時就會啟動歸檔：
            ● 在primary(假設有2個歸檔進程)，一旦ARC0進程完成redolog的歸檔，ARC1進程即開始傳輸該歸檔到standby的指定路徑
            ● 在standby，RFS進程輪流將redo資料寫入standby log，再由standby中的ARCn進程將其寫入歸檔，然後通過SQL apply將資料應用到standby資料庫

        ㈡ 使用LGWR歸檔即時同步redo資料
           使用LGWR進程與使用ARCn進程有明顯不同，LGWR無須等待日誌切換及完成歸檔
            ● 在primary，LGWR提交redo資料到LNSn(LGWR Network Server process)進程(n>0)，LNSn啟動網路傳輸
            ● 在standby的RFS(Remote File Server)將接收到的redo資料寫入standby log。在此期間，primary的事務會一直保持，直到所有含LGWR SYNC屬性的LOG_ARCHIVE_DEST_n指定路徑均已完成接收

        ㈢ 使用LGWR歸檔非同步redo資料
           大致步驟與同步傳輸相同，差別只在LNSn進程這裡，LGWR寫資料到online redolog
           LNSn進程訪問online redolog並傳輸資料到遠程standby的RFS而不再與本地LGWR之間有聯絡
           standby資料庫方面的處理邏輯仍然不變

 

        複製實現層級和資料保護模式
       
        MySQL Replication可以是基於statement level，也可以基於row level
        不同的複製層級會影響到Master的Binary Log記錄成不同的形式
         ① row level
            Binary Log會記錄成每一行資料被修改的形式，然後再Slave再對相同資料進行修改
            優點：
                ⒈ Row Level的日誌內容會非常清楚的記錄下每一行資料修改的細節，非常容易理解
                ⒉ 不存在某些情況下預存程序或function以及trigger的調用和觸發無法被正確複製的問題
            缺點：
                產生驚人的日誌量
         ② statement level
             每一條會修改資料的Query都會記錄到Master的Binary Log中。Slave 在複製的時候SQL線程會解析成和原來Master端執行過的相同的Query來再次執行
             優點：
                減少Binary Log日誌量，節約了IO成本，提高了效能
             缺點：
                ⒈ 必須級聯記錄每條語句在執行時的上下文資訊
                ⒉ 存在某些情況下預存程序或function以及trigger的調用和觸發無法被正確複製的問題
        

        
        Data Guard提供了三種資料保護的模式

        ① 最大保護(Maximum protection)：
           所有的事務在提交前至少一個standby資料庫redo資料被同步寫入
           如果出現了什麼故障導致standby資料庫停用話，primary資料庫會被shutdown
        ② 最高效能(Maximum performance)：
           事務可以隨時提交，當前primary資料庫的redo資料也需要至少寫入一個standby資料庫，不過這種寫入可以是不同步的
        ③ 最高可用性(Maximum availability)：
           和maximum protection一樣，至少一個standby資料庫redo資料被同步寫入
           不過與之不同的是，如果出現故障匯入無法同時寫入standby資料庫redo log，primary資料庫並不會shutdown
           而是自動轉為最高效能模式，等standby資料庫恢複正常之後，它又會再自動轉換成最高可用性模式