當前位置:首頁 » 數據倉庫 » mssql資料庫集群
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

mssql資料庫集群

發布時間: 2022-08-19 13:49:10

Ⅰ 雙機熱備下能創建MSsql資料庫復制嗎

你的資料庫是放在公共存儲上的嗎?「兩台資料庫名不同」是什麼意思?你在一個雙機組上承載了兩個資料庫?雙機用的什麼軟體?
雙機下是可以用資料庫復制的,發布和分發裝在單獨一台伺服器上就行了,也可以裝在雙機中的一台伺服器上,但在企業管理器中注冊的時候要用集群IP來注冊。
請說明你的環境,再幫你確定。

Ⅱ mysql集群是什麼意思

開在一台伺服器上,而是開到一個群組的所有伺服器上,一般20台為一個群組。
問:集群空間跟傳統空間的最大不同是什麼?
答:集群空間有數據同步和宕機檢測與智能解析域名的功能。
問:集群空間為什麼會比傳統空間穩定?
答:因為當客戶開通一個集群空間後集群空間系統就會把客戶的空間和站點資料同步到同
一個群組的所有伺服器上,一但當前訪問的伺服器不能正常工作時,智能系統就會把客
戶的域名解析到能正常工 作的伺服器上。
問:站點數據同步需要多長時間?
答:新開設的站點數據同步到所有伺服器上大概需要一個小時。如果站點數據小會更快。
問:站點參數(如:加減域名綁定)修改多長時間同步?
答:10分鍾內同步成功
問:當伺服器壞了多長時間會轉移到正常的伺服器上。
答:最長不會超過1分鍾,因為宕機檢測30秒一次,同時域名的重新解析也需要30秒才生
效。
問:站點跟資料庫是否可以開在同一台伺服器上?
答:最好不要,因為集群系統暫時還沒同步大型資料庫(mssql;mysql)。所以當伺服器不
能正常工作時,集群系統只是把您的站點轉移到別的伺服器上,並沒把資料庫也同時轉
移過去,所以最好把資料庫開設在群外的伺服器上。
問:集群空間是否支持開通php空間?
答:可以支持php,但還沒辦法同步mysql數據同步。將在二期工程實現.
問:集群空間跟傳統空間使用上有什麼不同?
答:考慮到用戶的方便使用,我們在設計的時候就本著盡量減少手工操作的思路,所以在使
用方面他們沒有太大的區別,唯一的區別是我們用免費提供的二級域名代替原來的IP,
也就是說使用傳統的空間時,用戶是把自己的域名解析到IP上,現在是作別名
(CNAME)解析到我們免費提供的二級域名,和登錄FTP的地址是我們提供的二級域
名。
問:域名本身(不帶www)如何作別名(CNAME)解析?
答:作別名解析的時候主機名不能為空,如果要給域名本身作別名解析請在主機名的位置上填寫noprefix ,提交後自然變為空。
問:集群空間是否能防CC攻擊?
答:集群空間系統本身沒防CC攻擊的功能。可我們也有自主開發的防CC攻擊防火牆可以屏蔽掉95%的攻擊IP。
問:正被攻擊的空間轉到集群空間是否馬上有效。
答:必須在您把站點資料傳到伺服器上大概三個小時才有效,因為系統把您的站點資料同步到同群內的所有伺服器上的過程需要大概三個小時。您站點資料比較少就會更快。

Ⅲ .net+MSSQL 單機伺服器 和 PHP+MYSQL 集群伺服器分別有什麼優點

.net+MSSQL

PHP+MYSQL
方便!推薦使用
.net+MSSQL

Ⅳ 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是在引擎里實現的不管怎麼樣有比沒有強!

Ⅵ 有6台WEB伺服器,跑著40多個網站,每個伺服器都有MSSQL資料庫,現在想把資料庫單獨拿出來放到一台伺服器上

比如說,資料庫一今天有更新,資料庫二必須數據和資料庫,比如說,資料庫一今天有更新,資料庫二必須數據和資料庫是一樣的,「當資料庫一伺服器掛了之後網站不受影響,轉去訪問資料庫伺服器二」
這個是網站程序去控制的,在資料庫連接配置文件里,寫個js或是php上面的小程序,當資料庫一錯誤,連接資料庫二。
下面是同步資料庫的配置:
兩台伺服器,分別安裝好Mysql,都安裝在 /usr/local/mysql 目錄下(安裝步驟省略,請參考相關文檔),兩台伺服器的IP分別是192.168.0.1和192.168.0.2,我們把192.168.0.1作為master資料庫,把192.168.0.2作為slave伺服器,我們採用單向同步的方式,就是master的數據是主的數據,然後slave主動去master哪兒同步數據回來。
兩台伺服器的配置一樣,我們把關鍵的配置文件拷貝一下,默認的配置文件是在 /usr/local/mysql/share/mysql目錄下,分別有 my-large.cnf, my-medium.cnf, my-small.cnf等幾個文家,我們只是測試,使用my-medium.cnf就行了。mysql安裝完後,默認的配置文件是指定在資料庫存放目錄下的,我們用的是4.1.X的,所以配置文件就應該在 /usr/local/mysql/var 目錄下,於是把配置文件拷貝過去:
cp /usr/local/mysql/share/mysql/my-medium.cnf /usr/local/mysql/var/my.cnf
兩台伺服器做相同的拷貝配置文件操作。
2. 配置Master伺服器
我們要把192.168.0.1配置為主mysql伺服器(master),那麼我們就要考慮我們需要同步那個資料庫,使用那個用戶同步,我們這里為了簡單起見,就使用root用戶進行同步,並且只需要同步資料庫abc。
打開配置文件:
vi /usr/local/mysql/var/my.cnf
找到一下信息:
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1 //1為master,2為salve
添加兩行:
sql-bin-update-same //同步形式
binlog-do-db = abc //要同步的資料庫
重啟192.168.0.1的mysql伺服器:
/usr/local/mysql/bin/mysqladmin shutdown
/usr/local/mysql/bin/mysqld_safe --user=mysql &
3. 配置Slave伺服器
我們的slave伺服器主要是主動去master伺服器同步數據回來,我們編輯配置文件:
vi /usr/local/mysql/var/my.cnf
找到下面類似的信息:
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1
把上面的server-id修改為2,同時添加一些信息:
server-id = 2 //本Mysql是slave伺服器
master-host = 192.168.0.1 //master伺服器的IP
master-user = root //連接master伺服器的用戶
master-password = '' //連接master伺服器的密碼
master-port = 3306 //連接埠
master-connect-retry = 10 //重試次數
replicate-do-db = abc //要同步的資料庫
log-slave-updates //同步的形式
重啟192.168.0.2的mysql伺服器:
/usr/local/mysql/bin/mysqladmin shutdown
/usr/local/mysql/bin/mysqld_safe --user=mysql &
4. 測試安裝
首先查看一下slave的主機日誌:
cat /usr/local/mysql/var/xxxxx_err (xxx是主機名)
檢查是否連接正常, 看到類似這樣的信息就成功了
051031 11:42:40 mysqld started
051031 11:42:41 InnoDB: Started; log sequence number 0 43634
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.15-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
051031 11:42:41 [Note] Slave SQL thread initialized, starting replication in log 'FIRST'

at position 0, relay log './new4-relay-bin.000001' position: 4
051031 11:43:21 [Note] Slave I/O thread: connected to master '[email protected]:3306',
replication started in log 'FIRST' at position 4
在Master查看信息
/usr/local/mysql/bin/mysql -u root
查看master狀態:
mysql> show master status;
查看Master下mysql進程信息:
mysql> show processlist;
在slave上查看信息:
/usr/local/mysql/bin/mysql -u root
查看slave狀態:
mysql> show slave status;
查看slave下mysql進程信息:
mysql> show processlist;
你再在master的abc庫里建立表結構並且插入數據,然後檢查slave有沒有同步這些數據,就能夠檢查出是否設置成功。
最後,如果有興趣的話,可以研究一下雙擊熱備份,或者一台master,多台slave的同步實現。

我是飲食web,如果看不懂可以追問,我上線了可以幫你解答

Ⅶ php mssql資料庫支持多少人同時上網

mssql壓力不了解。

網站同時多少人上網,這不單純和程序的問題,還和伺服器關系很大。
比如taobao的首頁,每天訪問以千萬為單位,人家都是集群伺服器。

並且,同時在線,並不代表每一個訪問都 一定會查詢數據

而且,同時在線,是指某一個短時間內在線,並不是同時去執行一個查詢。

一般的VPS,同時萬人,問題不大

Ⅷ 請問「介面伺服器」、「應用伺服器」 、「資料庫伺服器」分別是指什麼意思

資料庫:存儲數據的應用軟體。

伺服器:公共的服務庫。

應用伺服器是應用的伺服器,提供應用服務,也可以是自己的網路應用伺服器,介面伺服器是提供給第三方調用的服務,主要是為了自己的應用的安全性,所以只把能供給第三方調用的東西封裝在應用伺服器伺服器。

雖然Web伺服器可能不支持事務或資料庫連接,但可能具有容錯和可擴展性功能,如負載平衡,緩存和集群。

與資料庫伺服器不同,因為該伺服器執行諸如數據分析,存儲,數據處理,歸檔以及其他數據管理相關任務之類的任務。

資料庫伺服器使用諸如ODBC,JDBC等協議。他們還將託管資料庫,如Oracle,SQLServer,MySQL等。

(8)mssql資料庫集群擴展閱讀:

伺服器是計算機區域網的核心部件。網路操作系統是在網路伺服器上運行的,網路伺服器的效率直接影響整個網路的效率。

因此,一般要用高檔計算機或專用伺服器計算機作為網路伺服器。網路伺服器主要有以下4個作用:

運行網路操作系統,控制和協調網路中各計算機之間的工作,最大限度地滿足用戶的要求,並做出響應和處理。

存儲和管理網路中的共享資源,如資料庫、文件、應用程序、磁碟空間、列印機、繪圖儀等。

·為各工作站的應用程序服務,如採用客戶/伺服器(Client/Server)結構使網路伺服器不僅擔當網路伺服器,而且還擔當應用程序伺服器。

對網路活動進行監督及控制,對網路進行實際管理,分配系統資源,了解和調整系統運行狀態,關閉或啟動某些資源等。

參考資料:網路-網路伺服器

Ⅸ 什麼是sqlserver的集群

由二台或更多物理上獨立的伺服器共同組成的「虛擬」伺服器稱之為集群伺服器。一項稱做MicroSoft集群服務(MSCS)的微軟服務可對集群伺服器進行管理。一個SQL Server集群是由二台或更多運行SQL Server的伺服器(節點)組成的虛擬伺服器。如果集群中的一個節點發生故障,集群中的另一個節點就承擔這個故障節點的責任。
認為一個SQL Server集群能夠給集群中的兩個節點帶來負載平衡,這是一種常見的誤解。雖然這似乎很有用,但卻是不正確的。這也意味著集束SQL Server不能真正提高性能。集束SQL Server只能提供故障轉移功能。故障轉移就是當系統中的一台機器發生故障失去其功能時,另一台機器將接手運行它的SQL Server實例。這種功能失效可能是由於硬體故障、服務故障、人工故障或各種其它原因。
為何要集束SQL Server環境?
在實用性方面,集群SQL Server環境令人滿意。在進行故障轉移時,將資料庫實例由一台伺服器轉移到另一台伺服器的時間非常短暫,一般只需要3至7秒鍾。雖然需要重建連接,但對資料庫的終端用戶而言,故障轉移處理通常是透明的。低廉的故障轉移成本還可幫助你對集群中的節點進行維護,而不會造成伺服器完全無法訪問。
SQL Server集群類型
一共有兩種類型的SQL Server集群:主動/被動集群和主動/主動集群。下面分別對它們進行說明(說明以兩個節點的SQL Server集群為基礎)。
主動/被動集群
在這種類型的集群中,一次只有一個節點控制SQL Server資源。另一個節點一直處於備用模式,等待故障發生。進行故障轉移時,備用的節點即取得SQL Server資源的控制權。
優點:由於伺服器上只有一個實例在運行,所以在進行故障轉移時,不需要另外的伺服器來接管兩個SQL Server實例,性能也不會因此降低。
缺點:由於虛擬伺服器上只有一個SQL Server實例在運行,另一台伺服器總是處理備用模式與空閑狀態。這意味著你並沒有充分利用你購買的硬體。
主動/主動集群
在這種類型的集群中,集群中的每個節點運行一個獨立且主動的SQL Server實例。發生節點故障時,另一個節點能夠控制發生故障節點的SQL Server實例。然後這個正常的節點將運行兩個SQL Server實例——它自己的實例和發生故障的實例。
優點:通過這種配置,你能夠充分利用你的硬體。在這樣的系統中,兩個伺服器都在運行,而不是只有一台伺服器運行,而另一台處於等待故障發生的備用模式,因此你能夠充分利用你購買的機器。
缺點:如果進行故障轉移,一台伺服器運行兩個SQL Server實例,性能就會受到不利影響。然而,性能降低總比虛擬伺服器完全失靈要強得多。這種配置的另一故障在於它要求購買的許可要比主動/被動集群多一些。因為集群在運行兩個主動SQL Server實例,這要求你購買兩個單獨的伺服器許可。在某些情況下,這也可能對你形成阻礙。
集群考慮
在高實用性方面,集群SQL Server環境有一定的優勢。然而,高實用性也確實伴隨某種折衷。
首先,建立一個集群SQL Server環境非常昂貴。這是因為集群中的節點必須遵照集群節點的兼容性列表。而且,還需要建立一個復雜的網路,機器的配置必須幾乎相同,同時需要實現資料庫文件磁碟子系統共享。存儲區網路(SAN)是建立這種子系統的不錯選擇,但SAN並非必要,而且十分昂貴。另外,如果你正在運行一個主動/主動集群,你需要為集群中運行SQL Server實例的每台機器的處理器購買一個許可。
因為當地集群主要局限於同一地理區域,自然災難可能會使集群完全失靈。在那種情況下,你需要轉移到災難恢復站點進行繼續操作。你也可以建立地理分散的SQL Server集群,但這樣的系統更加復雜與昂貴。