RiCo技術農場

這篇來看看我如何在AlwaysOn中使用HAproxy，看看是否可以更有效利用Readable secondary。

SQL Server 2017設定AG和SQL 2014/2016大同小異，差異部分就是Linux 平台專屬

SQL Server 2017安裝SQL Server Failover Cluster基本上和SQL2014/16大同小異，

這篇記錄一下AA mode設定過程，但我得老實說，還是用AlwaysOn比較好啦。

Replication這高可用技術，從SQL2005來幾乎沒有多大改變(參考自己以前寫的文章)，

交易複寫我個人也很常用，不過，我對雙向複寫就很感冒了，因為以前我有一陣子時間，

每天上班都要花不少時間處理雙向replication問題，

這篇來看看搭配In-Memory OLTP有那些注意事項。

SQL2016 AlwaysOn的redo log效能和log傳送吞吐量有很大改善(是SQL2014的4~5倍)，

這篇來回顧一下AlwaysOn和In-Memory OLTP一些注意事項。

真實世界，大部分企業無法接受Database停止服務太久時間，

一般的backup and restore雖然可以達到目的，但由於backup and restore過程中，

還是有資料的新增、修改或刪除持續發生，雖然資料庫restore完成，

可是無法避免人工進行補資料和確認資料一致性作業，

這時你才會知道Mirroring的好處

備份作業可能會是一項耗用I/O和CPU(啟用備份壓縮)的繁重作業，這項作業可能會影響主要伺服器效能，

現在透過AlwaysOn AG將備份作業卸載至同步或同步中的次要複本，讓主要伺服器專用於生產應用程式。

SQL2012和SQL2014永遠只會讀取read-only routing list中第一個可用複本，

所以之前你可以透過Agent job定時修改routing list達到分流效果(非真正load balancing)，

但現在SQL2016可在多個可讀取次要複本，輕鬆實現Round-robin load balancing。

Alwayson2016 AG 可以提供企業

High Availability(HA):硬體故障、藍白畫面(BSODs)

Disaster Recovery(DR):快速災難復原(移轉)

Scale out:跨多台伺服器分擔workload

[SQL SERVER][HA]grant endpoint permission

[SQL SERVER][HA]建置交易式複寫(2)-遠端散發者

[SQL SERVER][HA]利用SQL Express打造Log Shipping

[SQL SERVER][Denali]SQL Server 2012: AlwaysOn Availability Groups

[SQL SERVER][HA]資料庫複寫#建置交易式複寫

[SQL SERVER][HA]資料庫複寫#簡介

[SQL SERVER][HA]資料庫鏡像#簡介

[SQL SERVER][HA]資料庫鏡像#實作同步資料庫鏡像

[SQL SERVER][HA]資料庫快照#測試

[SQL SERVER][HA]資料庫快照#簡介