sqlserver2008集群

① 做開發的朋友們，sqlServer大家都用什麼版本

各版本功能對比

從我最開始接觸的SQL SERVER 2000 開始，已經經歷了如此多的版本。下面簡單闡述下各個版本新增的功能：
SQL SERVER 2000
日誌傳送
索引視圖

SQL SERVER 2005
分區
資料庫鏡像
（只有 SQL Server 2005 Enterprise Edition SP1 和更高版本支持非同步資料庫鏡像。）
聯機索引
資料庫快照
復制
故障轉移群集
SQL SERVER 2008

數據壓縮
資源調控器
備份壓縮

SQL SERVER 2008 R2

R2標志表示這是SQL Server的一個中間版本，而不是一個主版本 .此版本目前我的客戶中，使用還是非常多，性能穩定，雖然新增功能比較少：
新增數據中心版，最大支持256核.
Unicode壓縮
(為Unicode存儲提供一個簡單的壓縮方案，通過Unicode壓縮，可以減少Unicode字元對空間的佔用)

SQL SERVER 2012

AlwaysOn
Columnstore 索引
增強的審計功能
大數據支持

SQL SERVER 2014
這個版本的新特效特別多，和非常有用，可以多了解下.

內存優化表
備份加密
針對基數估計的新設計
AlwaysOn 增強功能
延遲持續性 （將部分或所有事務指定為延遲持久事務，從而能夠縮短延遲）
分區切換和索引生成
(官網寫得Partition Switching and Indexing，感覺是有問題的，其實就是分區表的單個分區可以重建)
列存儲索引
緩沖池擴展 就是使用SSD 擴展緩沖池
增量統計信息
資源調控器增強功能
（--之前只能控制CPU和內存，2014 開始可以控制IO）
DBCC CHECK 支持maxdop 提示

SQL SERVER 2016

全程加密技術(Always Encrypted)
JSON支持
多TempDB資料庫文件
（以前也是支持的，在2014 開始就在error log提示,2016中，在安裝時就可以設置。）
Query Store
（前幾天去參加微軟的培訓還講到的，挺不錯的功能。可以幫助解決參數嗅探的問題，資料庫升級的時候也可以用到它）
支持R語言
Live Quer y St at ist ics
（可以更清晰的看到執行計劃的開銷（水流式））

SQL SERVER 2017
可恢復的在線索引重建
允許您在發生故障（例如故障切換到副本或磁碟空間不足）之後恢復在線索引重建操作。
IDENTITY_CACHE option
當此選項設置為OFF時，它可以避免在伺服器意外重新啟動或故障切換到輔助伺服器的情況下，標識列值的間隙
CLR在.NET Framework中使用代碼訪問安全性（CAS），該框架不再支持安全邊界。
使用PERMISSION_SET = SAFE創建的CLR程序集可能能夠訪問外部系統資源，調用非託管代碼並獲取sysadmin許可權
圖表資料庫功能
用於多對多關系建模
Read-scale availability groups without cluster
可以在不依賴集群的情況下，搭建讀的可用性組，分擔讀壓力。不過此時不能實現高可用。
R/PYTHON 機器學習方面的功能

總結
總的來說,SQL SERVER 正在變得越來越好，希望越來越多的人更多的了解他.如果有什麼其他疑問歡迎討論。

② windows2008+sqlserver2008搭建集群，故障轉移集群伺服器，點擊存儲，添加磁碟上，無法找到適用於群集磁碟

呵呵，深奧啊，我自己說說一起探討一下，我認為是3快硬碟安裝或載入的不符合群集磁碟的要求，沒有按照群集磁碟的要求來添加磁碟，你看看要把磁碟也添加到群集磁碟陣列中，應該怎麼操作，大家共同研究研究。

③ SQLSERVER怎麼搭建伺服器集群實現負載均衡

很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。

將SQL Server實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。

當尋找一個備用，比如高可用性的環境，企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。

什麼是Microsoft集群伺服器

MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。

這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。

MSCS不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。

在集群伺服器上的SQL Server

SQL Server 2000可以配置為最多4個節點的集群，而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後，它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。

SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助，「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」

注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其他的方法，比如log shipping和資料庫鏡像。

單個的大的SQL Server集群還是小的集群

下面是大的、由更多的節點組成的集群的優點：

◆更高的可用新(更多的節點來災難恢復)。

◆更多的負載均衡選擇(更多的節點)。

◆更低廉的維護成本。

◆增長的敏捷性。多達4個或者8個節點，依賴於SQL版本。

◆增強的管理性和簡化環境(需要管理的少了)。

◆更少的停機時間(災難恢復更多的選擇)。

◆災難恢復性能不受集群中的節點數目影響。

下面是單個大的集群的缺點：

◆集群節點數目有限(如果需要第9個節點怎麼辦)。

◆在集群中SQL實例數目有限。

◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。

◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。

虛擬化和集群

虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。SQL Server實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。

在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如，使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。

集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。

④ 如何實現mssql資料庫負載均衡

SQL Server 負載均衡集群
一個應用系統隨著業務量的提高,以及訪問量和數據流量的快速增長，各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬體升級，必將造成現有資源的浪費，而且下一次業務量的提升，又將導致再一次硬體升級的高額成本投入。於是，負載均衡機制應運而生。 對於應用系統的負載均衡的硬體和軟體比比皆是，因為應用伺服器上的程序基本上認為是不變化的，而且一般的各個應用伺服器上的程序是不交互的。因此應用伺服器的負載均衡非常好做，只需要能夠進行分流的軟體或者硬體把多個客戶端的連接分配到多個應用伺服器上去即可。
因為資料庫內的數據是頻繁變化的，為了數據的一致性以及鎖資源的分配協調等，所以像應用伺服器那樣只有分流是不夠的，各個節點需要頻繁的交互。這也是資料庫集群軟體難做的原因，當然也是賣的貴的原因了。

Oracle Real Application Clusters
對於資料庫負載均衡，大家最為耳熟能詳的就是Oracle RAC了。RAC是雙機並行伺服器(8i及以前版本稱作Oracle Parallel Server，OPS)，用來在集群環境下實現多機共享資料庫，以保證應用的高可用性，同時可以自動實現並行處理及均分負載，還能實現資料庫在故障時的排錯和無斷點恢復。它可以自動進行負載平衡、故障修復和規劃停機時間，以支持高可用性應用程序。若並行伺服器中某節點失效，透明的應用程序容錯能夠把用戶自動轉接到另一節點上繼續運行，應用程序在用戶沒有察覺的情況下繼續執行。這使周期性和非周期性發生故障的系統增大了連續可用性。進程的失效可以完全透明地轉移到另一節點上去，通過適當地配置，可以指定所有查詢都在客戶端進行緩存，這樣它們便可以在轉移後的節點上重新設置。
Moebius for SQL Server
截至到SQL Server 2008，微軟還是沒有推出負載均衡組件，只能靠第三方軟體來實現，好在這個軟體是幾個從微軟出來的人寫的，也算是個小小的巧合。說他們是微軟出來的並不是說他們的技術多厲害，而是他們利用SQL Server的一些內部介面把集群做的非常透明， 無論是應用程序的調用還是開發/管理人員的使用都和面對一個資料庫一樣。
他們的實現原理是這樣的：和SQL Server鏡像一樣，每個資料庫節點都有自己的數據，也就是無共享磁碟架構。他們稱之為「中間件」的程序宿主在資料庫的內部，每個節點資料庫上寫入數據導致數據變化時，SQL Server會激活「中間件」，「中間件」把變化的數據同步到其他的節點上。其他節點發生變化也是一樣。因為「中間件」宿主在資料庫內， 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起，也就是使用戶的執行和數據的同步成為一個原子操作，從而保證數據在每時每刻都是一致的。因此查詢可以隨便到每個機器上去查，從而做到了真正的負載均衡。
這是一種叫"資料庫路由器"的技術,這種技術的特點是靈活性好,但效率比RAC要低，畢竟RAC是在引擎里實現的不管怎麼樣有比沒有強!

⑤ 簡述mysql該怎樣進行集群部署

mysql集群部署操作如下：
1、在MySQL集群中.當table引擎為NDBCLUSTER時才做集群，其他非NDBCLUSTER表和一般MySQL資料庫表一樣，不會共享數據。NDBCLUSTER表數據存儲在Data node伺服器內存中，Data Node可以為1台或多台伺服器，它們之間存放共享數據。Data Node伺服器可以分組數據。
例如：2,3,4,5為四台Data Node伺服器ID. 2,3為組0； 4，5為組1； 2，3維持數據相同，4，5維持數據相同。 組0和組1維持數據不同。
2、sql node伺服器中，非NDBCLUSTER數據存在本身資料庫中，table引擎為NDBCLUSTER時，數據存儲在Data Node中。當查詢NDBCLUSTER表時，它會從Data node集群中提起數據.
3、Manager server管理SQl node和Data node狀態。