mysqlheartbeat共享存儲

⑴ 如何提高網站並發訪問性能

1、HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法
其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發布系統CMS，像我們常訪問的各個
門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管
理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發布類型的網站，對於交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化、有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。
同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現。
比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後台管理並且存儲在資料庫中，這些信息其實大量被前台程序調用，但是更新頻率很小，可以
考慮將這部分內容進行後台更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。
2、圖片伺服器分離
大家知道，對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基
本上大型網站都會採用的策略，他們都有獨立的、甚至很多台的圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為
圖片問題而崩潰。
在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持、盡可能少的LoadMole，保證更高的系統消耗和執行效率。
3、資料庫集群、庫表散列
大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是我們需要使用資料庫集群或者庫表散列。
在資料庫集群方面，很多資料庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的Mysql提供的Master/Slave也是類似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施即可。
上面提到的資料庫集群由於在架構、成本、擴張性方面都會受到所採用DB類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用並且最有效的解決方案。
我們在應用程序中安裝業務和應用或者功能模塊將資料庫進行分離，不同的模塊對應不同的資料庫或者表，再按照一定的策略對某個頁面或者功能進行更小的資料庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。
sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行資料庫分離，然後對帖子、用戶按照板塊和ID進行散列資料庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一台低成本的資料庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，linux上提供的Memory
Cache是常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大
型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多
了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常採用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網路接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和
ENet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現
成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量並發請求採用的高端解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
（1）、硬體四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。
第四層交換功能就像是虛IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業
務在物理伺服器基礎上，需要復雜的載量平衡演算法。在IP世界，業務類型由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP
地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。「Yahoo中國」當初接近2000台伺服器，只使用了三、四台Alteon就搞定了。
(2)、軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual
Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的強壯性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿
足多種應用需求，這對於分布式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會。有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大。
7、最新：CDN加速技術
什麼是CDN？
CDN的全稱是內容分發網路。其目的是通過在現有的Internet中增加一層新的網路架構，將網站的內容發布到最接近用戶的網路「邊緣」，使用戶可以就近取得所需的內容，提高用戶訪問網站的響應速度。
CDN有別於鏡像，因為它比鏡像更智能，或者可以做這樣一個比喻：CDN=更智能的鏡像+緩存+流量導流。因而，CDN可以明顯提高
Internet網路中信息流動的效率。從技術上全面解決由於網路帶寬小、用戶訪問量大、網點分布不均等問題，提高用戶訪問網站的響應速度。
CDN的類型特點
CDN的實現分為三類：鏡像、高速緩存、專線。
鏡像站點（Mirror Site），是最常見的，它讓內容直接發布，適用於靜態和准動態的數據同步。但是購買和維護新伺服器的費用較高，還必須在各個地區設置鏡像伺服器，配備專業技術人員進行管理與維護。對於大型網站來說，更新所用的帶寬成本也大大提高了。
高速緩存，成本較低，適用於靜態內容。Internet的統計表明，超過80%的用戶經常訪問的是20%的網站的內容，在這個規律下，緩存服務
器可以處理大部分客戶的靜態請求，而原始的伺服器只需處理約20%左右的非緩存請求和動態請求，於是大大加快了客戶請求的響應時間，並降低了原始伺服器的
負載。
CDN服務一般會在全國范圍內的關鍵節點上放置緩存伺服器。
專線，讓用戶直接訪問數據源，可以實現數據的動態同步。
CDN的實例
舉個例子來說，當某用戶訪問網站時，網站會利用全球負載均衡技術，將用戶的訪問指向到距離用戶最近的正常工作的緩存伺服器上，直接響應用戶的請求。
當用戶訪問已經使用了CDN服務的網站時，其解析過程與傳統解析方式的最大區別就在於網站的授權域名伺服器不是以傳統的輪詢方式來響應本地
DNS的解析請求，而是充分考慮用戶發起請求的地點和當時網路的情況，來決定把用戶的請求定向到離用戶最近同時負載相對較輕的節點緩存伺服器上。
通過用戶定位演算法和伺服器健康檢測演算法綜合後的數據，可以將用戶的請求就近定向到分布在網路「邊緣」的緩存伺服器上，保證用戶的訪問能得到更及時可靠的響應。
由於大量的用戶訪問都由分布在網路邊緣的CDN節點緩存伺服器直接響應了，這就不僅提高了用戶的訪問質量，同時有效地降低了源伺服器的負載壓力。

⑵ mysql資料庫可靠性分析

mysql資料庫有undo空間
5種mysql做可靠性分析的方案：
1．MySQL Clustering(ndb-cluster stogare)
簡介：
MySQL公司以存儲引擎方式提供的高可靠性方案，是事務安全的，實時復制數據，可用於需要高可靠性及負載均衡的場合。該方案至少需要三個節點伺服器才能達到較好的效果。
成本：
節點伺服器對RAM的需求很大，與資料庫大小呈線性比例；
最好使用千兆乙太網絡；
還需要使用Dolphin公司提供的昂貴的SCI卡。
優點：
可用於負載均衡場合；
可用於高可靠性場合；
高伸縮性；
真正的資料庫冗餘；
容易維護。
缺點：
隨著資料庫的變大，對RAM的需求變得更大，因此成本很高；
速度：
幾乎 比典型的單獨伺服器（無千兆乙太網，無SCI卡，存儲引擎相關的限制少）慢10倍。
應用場合：
冗餘，高可靠性，負載均衡
2. MySQL / GFS-GNBD/ HA (Active/Passive)
簡介：
如果多個MySQL伺服器使用共享硬碟作為數據存儲，此方案如何？
GFS/GNBD可以提供所需的共享硬碟。
GFS是事務安全的文件系統。同一時刻你可以讓一個MySQL使用共享數據。
成本：
最多n台高性能伺服器的成本，其中一個激活的，其他作為備份伺服器。
優點：
高可靠性
某種程度的冗餘
按照高可靠性進行伸縮
缺點：
沒有負載均衡
沒有保證的冗餘
無法對寫操作進行伸縮
速度：
單獨伺服器的2倍。對讀操作支持得較好。
應用場合：
需要高可靠性的、讀操作密集型的應用
3. MySQL / DRBD / HA (Active/Passive)
簡介：
如果多個MySQL伺服器使用共享硬碟作為數據存儲，此方案如何？
DRBD可以提供這樣的共享硬碟。DRBD可以被設置成事務安全的。
同一時刻你可以讓一個MySQL使用共享數據。
成本：
最多n台高性能伺服器的成本，其中一個激活的，而其他則作為備份伺服器。
優點：
高可靠性；
一定程度的冗餘；
以高可靠性名義來看是可伸縮的。
缺點：
沒有負載均衡
沒有保證的冗餘
在寫負載方面沒有伸縮性
速度：
在讀寫方面相當於單獨伺服器
應用場合
需要高可靠性、讀操作密集型的應用
4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)
簡介：
考慮不同的讀、寫DB資料庫連接的情況。可以使用一台主伺服器用於寫操作，而採用n台從伺服器用於讀操作。
成本：
最多1台高性能寫伺服器，n台讀伺服器的成本
優點:
讀操作的高可靠性；
讀操作的負載均衡；
在讀操作負載均衡方面是可伸縮的。
缺點：
無寫操作的高可靠性；
無寫操作的負載均衡；
在寫操作方面無伸縮性；
速度：
同單獨伺服器；在讀操作方面支持得較好
應用場合
讀操作密集型的、需要高可靠性和負載均衡的應用。
5. Standalone MySQL Servers(Functionally separated) (Active)
多台功能分離的單獨伺服器，沒有高可靠性、負載均衡能力，明顯缺點太多，不予考慮。

⑶ 基於MySQL雙主的高可用解決方案理論及實踐

MySQL在互聯網應用中已經遍地開花，但是在銀行系統中，還在生根發芽的階段。本文記錄的是根據某生產系統實際需求，對資料庫高可用方案從需求、各高可用技術特點對比、實施、測試等過程進行整理，完善Mysql高可用方案，同時為後續開展分布式資料庫相關測試做相應准備。

存儲復制技術： 傳統IOE架構下，常用高可用方案，靠存儲底層復制技術實現數據的一致性，優點數據安全性有保障，限制在於是依賴存儲硬體，實施成本較高。

keepalived+雙主復制： 兩台MySQL互為主從關系，即雙主模式，通過Keepalived配置虛擬IP，實現當其中的一台資料庫故障時，自動切換VIP到另外一台MySQL資料庫，備機快速接管業務來保證資料庫的高可用。

MHA： MHA部署在每台mysql伺服器上，定時探測集群中的master節點，當master出現故障時，它可以自動將最新的slave提升為新的master，然後將所有其他的slave重新指向新的master，優點在最大程度保證數據的一致性的前提下實現快速切換，最少需要3台伺服器，存在數據丟失的可能性。

PXC： Percona eXtra Cluster是Percona基於galera cluster封裝的集群方案。不同於普通多主復制，PXC保障強一致性和實時同步，故障切換更快。但是也需要3個節點，配置相對復雜，對性能也稍有影響。

除了上述方案外，還有MMM、Heartbeat+DRBD等高可用方案，此處不做詳細介紹。

綜合評估下，本次實施採用了 keepalived+mysql雙主實現資料庫同城雙機房的高可用。MySQL版本為： 5.7.21。操作系統：Red Hat Enterprise Linux Server 7.3。

配置過程如下：

Mysql-master1: IP地址1 --以下簡稱master1

Mysql-master2: IP地址2 --以下簡稱master2

Mysql-vip : VIP地址 --應用連接使用

Mysql復制相關概念描述：

1、 Mysql主從復制圖示：

2、 Mysql主從復制過程描述：

（1）master記錄二進制日誌：在每個事務更新數據完成之前，master在二進制日誌記錄這些改變。MySQL將事務寫入二進制日誌。在事務寫入二進制日誌完成後，master通知存儲引擎提交事務。

（2）slave將master的binarylog拷貝到自己的中繼日誌：首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然後開始binlog mp process。Binlog mp process從master的二進制日誌中讀取事務，如果已經同步了master，它會睡眠並等待master產生新的事件。I/O線程將這些事務寫入中繼日誌。

（3）SQL slave thread處理該過程的最後一步：SQL線程從中繼日誌讀取事務，並重放其中的事務而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌通常會位於OS的緩存中，所以中繼日誌的開銷很小。

主主同步就是兩台機器互為主的關系，在任何一台機器上寫入都會同步至備端。

為了便於後續資料庫伺服器的擴展，且在整個復制環境中能夠自動地切換，降低運維成本，引入了當前主流的基於Mysql GTID的復制特性，工作原理及優缺點簡介如下。

3、 GTID工作原理簡介：

（1） master更新數據時，會在事務前產生GTID，一同記錄到Binlog日誌中。

（2） slave的I/O線程將變更的binlog寫入到本地的relay log中。

（3） slave的sql線程從relay log中獲取GTID，然後對比slave端的binlog是否有記錄。

（4） 如果有記錄說明該GTID的事務已經執行，slave會忽略。

（5） 如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。

（6） 在解析的過程中會判斷是否有主鍵，如果有就用索引，如果沒有就用全部掃描。

4、 GTID優點：

（1） 一個事務對應一個唯一的ID，一個GTID在一個伺服器上 只會執行一次。（2） GTID是用來替代傳統復制的方法，GTID復制與普通復制模式的最大不同就是不需要指定二進制文件名和位置。

（3） 減少手工干預和降低服務故障時間，當主機宕機之後會通過軟體從眾多的備機中提升一台備機為新的master。

5、 GTID也存在一些限制：

（1） 不支持非事務引擎。

（2） 不支持create table … select 語句復制(主庫直接報錯)。

（3） 不允許一個sql同時更新一個事務引擎表和非事務引擎表。

（4） 在一個復制組中，必須要求統一開啟GTID或者是統一關閉GTID。

（5） 開啟GTID需要重啟(5.7版本除外)。

（6） 開啟GTID後，就不再使用原理的傳統復制方式。

（7） 不支持create temporary table 和 drop temporary table語句。

（8） 不支持sql_slave_skip_counter。

前置條件：

主備兩個節點使用行內統一的安裝部署腳本安裝mysql5.7.21介質(略)

Master1端創建應用的資料庫(略)

1、 修改MySQL配置文件

參考相關配置規范，分別設置master1、master2的my.cnf文件，

其中server-id參數設置為不同值;

由於後續keepalived會掛起VIP，應用通過VIP連接資料庫，為了避免應用程序無法通過VIP訪問，需將兩個節點的bind-address參數注釋掉；

2、 設置master1端自動半同步模式

Mysql的同步模式主要有如下3種：

a. 主從同步復制：數據完整性好，但是性能消耗略高；

b. 主從非同步復制：性能消耗低，但容易出現不一致；

c. 主從半自動復制：介於上述兩種之間，既保持了數據的完整性，又提高了性能；

基於上述特性，建議採用半自動同步模式，由於後續要配置為雙主模式，因此任一節點其角色既為master又為slave，因此相關的master/slave插件要同時配置，過程如下。

（1） 首先查看庫是否支持動態載入(默認都支持)

（2） 主從庫上分別安裝插件

作為主庫，安裝插件semisync_master.so

作為從庫，安裝插件semisync_slave.so

（3） 安裝完成後，從plugin表中能夠看到剛剛安裝的插件

（4） 分別打開主從庫半同步復制

同時添加到各自的my.cnf中，在後續資料庫實例重啟時自動載入該配置。

此時查看狀態還沒有啟動

（5） 兩個節點分別啟動IO進程

（6） 查看半同步狀態

3、 將master1設為master2的主伺服器

（1）在master1主機上創建授權賬戶，允許在master2主機上連接

（2）將主庫master1數據導出

（3）將master.sql傳輸到master2上並導入

（4）在master2端將master1設置為自己的主庫，並開啟slave功能

在master2上查看slave狀態

至此master1到master2的主從復制關系已經建立完成。

4、 將master2設為master1的主伺服器

在master1上執行

在master1上查看slave狀態

1、keepalived相關概念說明：

keepalived是集群管理中保證集群高可用的一個軟體解決方案，其功能類似於heartbeat，用來防止單點故障

keepalived是以VRRP協議為實現基礎的，VRRP全稱VirtualRouter Rendancy Protocol，即虛擬路由冗餘協議。

虛擬路由冗餘協議，可以認為是實現路由器高可用的協議，即將N台提供相同功能的路由器組成一個路由器組，這個組裡面有一個master和多個backup，master上面有一個對外提供服務的vip，master會發組播（組播地址為224.0.0.18），當backup收不到vrrp包時就認為master宕掉了，這時就需要根據VRRP的優先順序來選舉一個backup當master，這樣的話就可以保證路由器的高可用了。

keepalived主要有三個模塊，分別是core 、check和vrrp。core模塊為keepalived的核心，負責主進程的啟動、維護以及全局配置文件的載入和解析。check負責 健康 檢查，包括常見的各種檢查方式。vrrp模塊是來實現VRRP協議的。同時為了避免出現腦裂，應關閉防火牆或者開啟防火牆但允許接收VRRP協議。

2、keepalived的安裝配置

（1）配置本地yum源，在master1和master2兩台伺服器上安裝keepalived的相關依賴包Kernel-devel/openssl-devel/popt-devl等

配置指向rhel-7.5.iso的yum本地源，步驟略

注意：如不知道keepalived需要哪些依賴包，可到下載後的源碼解壓目錄下查看INSTALL 文件內容，安裝需要的依賴包，源碼安裝任何一個軟體都要養成查看源碼包文檔的習慣，比如INSTALL，README,doc等文檔，可以獲得很多有用的信息。

（2）在兩台mysql上解壓縮並編譯安裝keepalived

（3）master1、master2上分別配置keepalived.conf

注意上圖紅色字體中兩個節點配置相同處及差異。

說明：keepalived只有一個配置文件keepalived.conf，裡面主要包括以下幾個配置區域：

· global_defs：主要是配置故障發生時的通知對象以及機器標識。

· vrrp_instance：用來定義對外提供服務的VIP區域及其相關屬性。

· virtual_server：虛擬伺服器定義

（4）同時兩個節點上都需要添加檢測腳本

作用：是當mysql停止工作時自動關閉本機的keeplived服務，從而實現將故障主機踢出熱備組，因每台機器上keepalived只添加了本機為realserver，所以當mysqld正常啟動後，我們還需要手動啟動keepalived服務。

（5）分別啟動兩個節點的keepalived服務

檢查兩個節點keepalived啟動進程

檢查兩個節點的vip掛載情況

（6）主備機故障切換測試

停止master2的mysql服務，看keepalived 健康 檢查程序是否會觸發腳本，自動進行故障切換，步驟略

查看master1節點的VIP掛載情況，驗證是否實現了自動切換，步驟略

說明在master2伺服器的mysql服務發生故障時，觸發了腳本，自動完成了切換。

（7）現在我們把master2的mysql服務開起來，並且keepalived的服務也需要啟動。

即便master2的mysql服務和keepalived服務都重新開啟了，master1仍然是主master了，master2未對主master的權利進行搶奪，說明設置的nopreempt參數生效了，為了保證群集的穩定性，生產環境不允許搶占配置，只有當master1的mysql服務壞掉的時候，master2才會再次成為主master，否則它永遠只能當master1的備份。（註：nopreempt一般是在優先順序高的mysql上設置）

Sysbench是一個模塊化的、跨平台、多線程基準測試工具，可用於評估資料庫負載情況，通過sysbench命令配置IP地址、埠號、用戶名、密碼連接到指定的資料庫db1中，創建多個表，並快速插入指定條數的記錄，觀察主備庫同步效率

(1) 下載開源工具sysbench-0.4.12.14.tar.gz，放置在相應目錄下並解壓

(2) 使用iso配置本地yum源並安裝Sysbench如下的依賴包(步驟略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc

(3) 編譯sysbench

編輯配置文件/etc/ld.so.conf中添加mysql lib目錄/mysql/app/5.7.21/lib，並執行命令ldconfig生效

(4) 執行sysbench壓測

使用sysbench工具向主節點的db1資料庫中創建5張表，並且每張表分別插入10萬條記錄

同時觀察備機同步效率

幾個重要的參數說明：

B、半自動同步模式、非同步模式切換測試

(1) 檢查主備同步狀態，及同步參數設置

rpl_semi_sync_master_enabled參數表示啟用半同步模式；

rpl_semi_sync_master_timeout參數單位為毫秒，表示主庫事務等待從庫返回commit成功信息超過10秒就降為非同步模式，不再等待從庫，等探測到從庫io線程恢復後，再返回為半自動同步；

rpl_semi_sync_master_wait_no_slave參數表示事務提交後需要等待從庫返回確認信息；

(2) 將slave的io線程停止

(3) 使用sysbench向master寫入少量的數據，本例創建一張表，並插入10條記錄，命令包裝在1.sh測試腳本中

通過記錄的時間戳發現，master在等待了slave10秒無響應，自動切換為非同步模式，將數據寫入本地。

(4) Slave啟動io線程，數據自動追平

至此MySQL主主復制配置完成，運行在半自動同步模式，通過keepalived實現Mysql的HA高可用。

上線後應符合統一的標准監控策略，添加備份協議對數據進行周期備份並保存到帶庫中，以及定期的數據恢復測試。

由於是靠keepalived實現的高可用，還應將如下資源添加到監控管理平台：

1、 對每台資料庫主機的3個keepalived進程進行監控；

2、 對主備節點的io線程、sql線程工作狀態進行監控；

⑷ 查看mysql是否為雙機

mysql雙機熱備實現原理分析，在本文經過深思熟慮和多次用不同的方式實測試後。最後在這篇文章中，用一個小例子來完成mysql雙機熱備的實現。

Mysql資料庫沒有增量備份的機制，當數據量太大的時候備份是一個很大的問題。還好mysql資料庫提供了一種主從備份的機制，其實就是把主資料庫的所有的數據同時寫到備份的資料庫中。實現mysql資料庫的熱備份。

要想實現雙機的熱備，首先要了解主從資料庫伺服器的版本的需求。要實現熱備mysql的版本都高於3.2。還有一個基本的原則就是作為從資料庫的數據版本可以高於主伺服器資料庫的版本，但是不可以低於主伺服器的資料庫版本。

當然要實現mysql雙機熱備，除了mysql本身自帶的REPLICATION功能可以實現外，也可以用Heartbeat這個開源軟體來實現。不過本文主要還是講如何用mysql自帶的REPLICATION來實現mysql雙機熱備的功能。



1. 准備伺服器



由於Mysql不同版本之間的（二進制日誌）binlog格式可能會不太一樣，因此最好的搭配組合是主（Master）伺服器的Mysql版本和從（Slave）伺服器版本相同或者更低，主伺服器的版本肯定不能高於從伺服器版本。

本次我用於測試的兩台伺服器版本都是Mysql-5.5.17。

2. Mysql 建立主－從伺服器雙機熱備配置步驟



2.1環境描述

A伺服器（主伺服器Master）：59.151.15.36

B伺服器（從伺服器Slave）：218.206.70.146

主從伺服器的Mysql版本皆為5.5.17

Linux環境下

將主伺服器需要同步的資料庫內容進行備份一份，上傳到從伺服器上，保證始初時兩伺服器中資料庫內容一致。

不過這里說明下，由於我是利用Mysql在安裝後就有的資料庫test進行測試的，所以兩台伺服器裡面是沒有建立表的，只不分別在test裡面建立了同樣的一張空表tb_mobile;

Sql語句如下：

mysql> create table tb_mobile( mobile VARCHAR(20) comment'手機號碼', time timestamp DEFAULT now() comment'時間' );

2.2 主伺服器Master配置

2.2.1 創建同步用戶

進入mysql操作界面，在主伺服器上為從伺服器建立一個連接帳戶，該帳戶必須授予REPLICATION SLAVE許可權。因為從mysql版本3.2以後就可以通過REPLICATION對其進行雙機熱備的功能操作。

操作指令如下：

mysql> grant replication slave on *.* to 'replicate'@餲.206.70.146' identified by �'

mysql> flush privileges;

創建好同步連接帳戶後，我們可以通過在從伺服器（Slave）上用replicat帳戶對主伺服器（Master）資料庫進行訪問下，看下是否能連接成功。

在從伺服器（Slave）上輸入如下指令：

[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456

如果出現下面的結果，則表示能登錄成功，說明可以對這兩台伺服器進行雙機熱備進行操作。2.2.2 修改mysql配置文件

如果上面的准備工作做好，那邊我們就可以進行對mysql配置文件進行修改了，首先找到mysql配置所有在目錄，一般在安裝好mysql服務後，都會將配置文件復制一一份出來放到/ect目錄下面，並且配置文件命名為：my.cnf。即配置文件准確目錄為/etc/my.cnf

(Linux下用rpm包安裝的MySQL是不會安裝/etc/my.cnf文件的，

至於為什麼沒有這個文件而MySQL卻也能正常啟動和作用，在點有兩個說法，

第一種說法，my.cnf只是MySQL啟動時的一個參數文件，可以沒有它，這時MySQL會用內置的默認參數啟動，

第二種說法，MySQL在啟動時自動使用/usr/share/mysql目錄下的my-medium.cnf文件，這種說法僅限於rpm包安裝的MySQL，

解決方法，只需要復制一個/usr/share/mysql目錄下的my-medium.cnf文件到/etc目錄，並改名為my.cnf即可。)

找到配置文件my.cnf打開後，在[mysqld]下修改即可：

[mysqld]

server-id = 1

log-bin=mysql-bin //其中這兩行是本來就有的，可以不用動，添加下面兩行即可

binlog-do-db = test

binlog-ignore-db = mysql

2.2.3 重啟mysql服務

修改完配置文件後，保存後，重啟一下mysql服務，如果成功則沒問題。2.2.4 查看主伺服器狀態

進入mysql服務後，可通過指令查看Master狀態，輸入如下指令：注意看裡面的參數，特別前面兩個File和Position，在從伺服器（Slave）配置主從關系會有用到的。

註：這里使用了鎖表，目的是為了產生環境中不讓進新的數據，好讓從伺服器定位同步位置，初次同步完成後，記得解鎖。2.3 從伺服器Slave配置

2.3.1修改配置文件

因為這裡面是以主－從方式實現mysql雙機熱備的，所以在從伺服器就不用在建立同步帳戶了，直接打開配置文件my.cnf進行修改即可，道理還是同修改主伺服器上的一樣，只不過需要修改的參數不一樣而已。如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

2.3.2重啟mysql服務

修改完配置文件後，保存後，重啟一下mysql服務，如果成功則沒問題。2.3.3用change mster 語句指定同步位置

這步是最關鍵的一步了，在進入mysql操作界面後，輸入如下指令：

mysql>stop slave; //先停步slave服務線程，這個是很重要的，如果不這樣做會造成以下操作不成功。

mysql>change master to

>master_host=ཷ.151.15.36',master_user='replicate',master_password=�',

> master_log_file=' mysql-bin.000016 ',master_log_pos=107;

註：master_log_file, master_log_pos由主伺服器（Master）查出的狀態值中確定。也就是剛剛叫注意的。master_log_file對應File, master_log_pos對應Position。Mysql 5.x以上版本已經不支持在配置文件中指定主伺服器相關選項。

遇到的問題，如果按上面步驟之後還出現如下情況：則要重新設置slave。指令如下

mysql>stop slave;

mysql>reset slave;

之後停止slave線程重新開始。成功後，則可以開啟slave線程了。

mysql>start slave;

2.3.4查看從伺服器（Slave）狀態

用如下指令進行查看

mysql> show slave statusG;查看下面兩項值均為Yes，即表示設置從伺服器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

2.4 測試同步

之前開始已經說過了在資料庫test只有一個表tb_mobile沒有數據，我們可以先查看下兩伺服器的資料庫是否有數據：

Master:59.151.15.36Slave:218.206.70.146好了，現在可以在Master伺服器中插入數據看下是否能同步。

Master:59.151.15.36Slave:218.206.70.146可以從上面兩個截圖上看出，在Master伺服器上進行插入的數據在Slave伺服器可以查到，這就表示雙機熱備配置成功了。

3. Mysql 建立主－主伺服器雙機熱備配置步驟

伺服器還是用回現在這兩台伺服器

3.1創建同步用戶

同時在主從伺服器建立一個連接帳戶，該帳戶必須授予REPLIATION SLAVE許可權。這里因為伺服器A和伺服器B互為主從，所以都要分別建立一個同步用戶。

伺服器A：

mysql> grant replication slave on *.* to 'replicate'@餲.206.70.146' identified by �'

mysql> flush privileges;

伺服器B：

mysql> grant replication slave on *.* to 'replicate'@ཷ.151.15.36' identified by �'

mysql> flush privileges;

3.2修改配置文件my.cnf

伺服器A

[mysqld]

server-id = 1

log-bin=mysql-bin

binlog-do-db = test

binlog-ignore-db = mysql

#主－主形式需要多添加的部分

log-slave-updates

sync_binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

replicate-do-db = test

replicate-ignore-db = mysql,information_schema

伺服器B：

[mysqld]

server-id = 2

log-bin=mysql-bin

master-slave need

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema



#主－主形式需要多添加的部分

binlog-do-db = test

binlog-ignore-db = mysql

log-slave-updates

sync_binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

3.3分別重啟A伺服器和B伺服器上的mysql服務

重啟伺服器方式和上面的一樣，這里就不做講解了。

3.4分別查A伺服器和B伺服器作為主伺服器的狀態

伺服器A：

伺服器B：3.5分別在A伺服器和B伺服器上用change master to 指定同步位置

伺服器A：

mysql>change master to

>master_host=餲.206.70.146',master_user='replicate',master_password=�',

> master_log_file=' mysql-bin.000011 ',master_log_pos=497;

伺服器B：

mysql>change master to

>master_host=ཷ.151.15.36',master_user='replicate',master_password=�',

> master_log_file=' mysql-bin.000016 ',master_log_pos=107;

3.6 分別在A和B伺服器上重啟從服務線程

mysql>start slave;

3.7 分別在A和B伺服器上查看從伺服器狀態

mysql>show slave statusG;

查看下面兩項值均為Yes，即表示設置從伺服器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

3.8 測試主－主同步例子

測試伺服器A：

在伺服器A上插入一條語句如下圖所示：

之後在伺服器B上查看是否同步如下圖所示：

測試伺服器B：

在伺服器B上插入一條語句如下圖所示：然後在從伺服器A上查看是否有同步數據如下圖所示：最後從結果可以看出主－主形式的雙機熱備是能成功實現的。

4. 配置參數說明

Server-id

ID值唯一的標識了復制群集中的主從伺服器，因此它們必須各不相同。Master_id必須為1到232－1之間的一個正整數值，slave_id值必須為2到232－1之間的一個正整數值。

Log-bin

表示打開binlog，打開該選項才可以通過I/O寫到Slave的relay-log，也是可以進行replication的前提。

Binlog-do-db

表示需要記錄二進制日誌的資料庫。如果有多個數據可以用逗號分隔，或者使用多個binlog-do-dg選項。

Binglog-ingore-db

表示不需要記錄二進制日誌的資料庫，如果有多個資料庫可用逗號分隔，或者使用多binglog-ignore-db選項。

Replicate-do-db

表示需要同步的資料庫，如果有多個數據可用逗號分隔，或者使用多個replicate-do-db選項。

Replicate-ignore-db

表示不需要同步的資料庫，如果有多個資料庫可用逗號分隔，或者使用多個replicate-ignore-db選項。

Master-connect-retry

master-connect-retry=n表示從伺服器與主伺服器的連接沒有成功，則等待n秒（s）後再進行管理方式（默認設置是60s）。如果從伺服器存在mater.info文件，它將忽略些選項。

Log-slave-updates

配置從庫上的更新操作是否寫入二進制文件，如果這台從庫，還要做其他從庫的主庫，那麼就需要打這個參數，以便從庫的從庫能夠進行日誌同步。

Slave-skip-errors

在復制過程，由於各種原因導致binglo中的sql出錯，默認情況下，從庫會停止復制，要用戶介入。可以設置slave-skip-errors來定義錯誤號，如果復制過程中遇到的錯誤是定義的錯誤號，便可以路過。如果從庫是用來做備份，設置這個參數會存在數據不一致，不要使用。如果是分擔主庫的查詢壓力，可以考慮。

Sync_binlog=1 Or N

Sync_binlog的默認值是0，這種模式下，MySQL不會同步到磁碟中去。這樣的話，Mysql依賴操作系統來刷新二進制日誌binary log，就像操作系統刷新其他文件的機制一樣。因此如果操作系統或機器（不僅僅是Mysql伺服器）崩潰，有可能binlog中最後的語句丟失了。要想防止這種情況，可以使用sync_binlog全局變數，使binlog在每N次binlog寫入後與硬碟同步。當sync_binlog變數設置為1是最安全的，因為在crash崩潰的情況下，你的二進制日誌binary log只有可能丟失最多一個語句或者一個事務。但是，這也是最慢的一種方式（除非磁碟有使用帶蓄電池後備電源的緩存cache,使得同步到磁碟的操作非常快）。

即使sync_binlog設置為1，出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。如果使用InnoDB表，Mysql伺服器處理COMMIT語句，它將整個事務寫入binlog並將事務提交到InnoDB中。如果在兩次操作之間出現崩潰，重啟時，事務被InnoDB回滾，但仍然存在binlog中。可以用-innodb-safe-binlog選項來增加InnoDB表內容和binlog之間的一致性。（注釋：在Mysql 5.1版本中不需要-innodb-safe-binlog；由於引入了XA事務支持，該選項作廢了），該選項可以提供更大程度的安全，使每個事務的binlog(sync_binlog=1)和（默認情況為真）InnoDB日誌與硬碟同步，該選項的效果是崩潰後重啟時，在滾回事務後，Mysql伺服器從binlog剪切回滾的InnoDB事務。這樣可以確保binlog反饋InnoDB表的確切數據等，並使從伺服器保持與主伺服器保持同步（不接收回滾的語句）。

Auto_increment_offset和Auto_increment_increment

Auto_increment_increment和auto_increment_offset用於主－主伺服器（master-to-master）復制，並可以用來控制AUTO_INCREMENT列的操作。兩個變數均可以設置為全局或局部變數，並且假定每個值都可以為1到65,535之間的整數值。將其中一個變數設置為0會使該變數為1。

這兩個變數影響AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset確定AUTO_INCREMENT列值的起點。

如果auto_increment_offset的值大於auto_increment_increment的值，則auto_increment_offset的值被忽略。例如：表內已有一些數據，就會用現在已有的最大自增值做為初始值。

⑸ mysql為什麼能用nfs作為共享存儲

還是先上規劃圖

1.首先進行資源的分析

1）Vip

2）Mysqld

3）Nfs

理清他們之間的啟動先後順序：nfs必須在Mysqld前啟動

2.nfs的配置

Nfs共享目錄上掛載的分區，最好做成lvm，實現自動擴展

2.1.安裝

#yum-yinstallnfs-utils

2.2配置

#mkdir/share

#vim/etc/exports

172.16.98.3:/share172.16.98.1(rw,no_root_squash)172.16.98.2(rw,no_root_squash)

#servicenfsstart

#groupadd-g186mysql

#useradd-u186-gmysql-s/sbin/nologin-Mmysql

#chownmysql:mysql/share

3.Mysql1結合nfs的安裝測試

3.1掛載nfs

#mkdir/data

#chownmysql:mysql/data

#mount172.16.98.3:/share/data

3.2使用mysql的解壓縮包安裝

#groupadd-g186mysql

#useradd-u186-gmysql-s/sbin/nologin-Mmysql

*在三台機器上，創建的mysql組和用戶的uid、gid要保持一致

#tarxfmysql-5.5.24-linux2.6-i686.tar.gz-C/usr/local

#cd/usr/local

#ln-smysql-5.5.24-linux2.6-i686mysql

#cdmysql

#chown-Rmysql:mysql.

#scripts/mysql_install_db--user=mysql--datadir=/data

#chowm-Rroot.

#cpsupport-files/my-large.cnf/etc/my.cnf

#cpcpsupport-files/mysql.server/etc/rc.d/init.d/mysqld

#chmod+x/etc/rc.d/init.d/mysqld

#vim/etc/profile

PATH=$PATH:/usr/local/mysql/bin

#exportPATH=$PATH:/usr/local/mysql/bin

3.3編輯配置文件,啟動服務

#vim/etc/my.cnf

[mysqld]

thread_concurrency=2

datadir=/data

#servicemysqldstart

3.4另一台mysql的安裝

參考前面的步驟

需要說明一點的是

Mysql的安裝，這里不需要再初始化mysql

##tarxfmysql-5.5.24-linux2.6-i686.tar.gz-C/usr/local

#cd/usr/local

#ln-smysql-5.5.24-linux2.6-i686mysql

#cdmysql

#chowm-Rroot.

#cpsupport-files/my-large.cnf/etc/my.cnf

#cpcpsupport-files/mysql.server/etc/rc.d/init.d/mysqld

#chmod+x/etc/rc.d/init.d/mysqld

#vim/etc/profile

PATH=$PATH:/usr/local/mysql/bin

#exportPATH=$PATH:/usr/local/mysql/bin

#servicemysqldstart

#cd/data

#

3.5停止所有資源

1）關閉mysql服務

2）將nfs共享目錄卸載

4.Corosync的安裝

前期准備

1）ssh雙機互信，方便配置

2）時間保持一致

3）/etc/hosts,主機名設置，互相解析

4.1corosync的安裝,兩台都安裝上

##yuminstall-ycluster-glue-1.0.6-1.6.el5.i386.rpmcluster-glue-libs-1.0.6-1.6.el5.i386.rpmcorosynclib-1.2.7-1.1.el5.i386.rpmcorosync-1.2.7-1.1.el5.i386.rpmheartbeat-3.0.3-2.3.el5.i386.rpmheartbeat-libs-3.0.3-2.3.el5.i386.rpmlibesmtp-1.0.4-5.el5.i386.rpmpacemaker-cts-1.1.5-1.1.el5.i386.rpmpacemaker-libs-1.1.5-1.1.el5.i386.rpmpacemaker-1.1.5-1.1.el5.i386.rpmperl-TimeDate-1.16-5.el5.noarch.rpmresource-agents-1.0.4-1.1.el5.i386.rpm

4.2corosync的配置

1）mysql1

#cd/etc/corosync

#cpcorosync.conf.examplecorosync.conf

#vimcorosync.conf

compatibility:whitetank

totem{

version:2

secauth:on開啟身份驗證

threads:0

interface{

ringnumber:0

bindnetaddr:172.16.0.0

mcastaddr:226.94.1.1

mcastport:5405

}

}

logging{

fileline:off

to_stderr:on

to_logfile:yes

#to_syslog:yes

logfile:/var/log/cluster/corosync.log

debug:off

timestamp:on

logger_subsys{

subsys:AMF

debug:off

}

}

amf{

mode:disabled

}

service{

ver:0

name:pacemaker

}

#corosync-keygen創建authkeys

#scpauthkeyscorosync.confnode2:/etc/corosync

兩台mysql上分別創建用於日誌的目錄

#mkdir/var/log/cluster

4.3通過mysql1開啟corosync，配置資源

1)開啟

#servicecorosyncstart

#sshnode2'servicecorosyncstart'

#crm_mon

============

Lastupdated:ThuAug922:12:222012

Stack:openais

CurrentDC:node1.7ing.com-partitionwithquorum

Version:1.1.5-1.1.el5-

2Nodesconfigured,2expectedvotes

0Resourcesconfigured.

============

Online:[node2.7ing.comnode1.7ing.com]

2）資源的配置

#crm

crm(live)#configure

crm(live)configure#primitivevipocf:heartbeat:IPaddrparamsip=172.16.99.1

crm(live)configure#primitivemysqldlsb:mysqld

crm(live)configure#primitivenfsocf:heartbeat:Filesystemparamsdevice=172.16.98.3:/sharedirectory=/datafstype=nfsopstarttimeout=60opstoptimeout=60

*定義nfs資源，默認的超時時間是20s，是小於建議的時間60s的，所以手動配置

crm(live)configure#colocationvip_mysqld_nfsinf:mysqldnfsvip

crm(live)configure#ordermysqld_after_nfsinf:nfsmysqld

crm(live)configure#propertystonith-enabled=false

crm(live)configure#propertyno-quorum-policy=ignore

crm(live)configure#verify

crm(live)configure#commit

3）檢測

#crm_mon

Lastupdated:ThuAug922:34:522012

Stack:openais

CurrentDC:node1.7ing.com-partitionwithquorum

Version:1.1.5-1.1.el5-

2Nodesconfigured,2expectedvotes

3Resourcesconfigured.

============

Online:[node2.7ing.comnode1.7ing.com]

nfs(ocf::heartbeat:Filesystem):Startednode1.7ing.com

vip(ocf::heartbeat:IPaddr):Startednode1.7ing.com

mysqld(lsb:mysqld):Startednode1.7ing.com

#crmnodestandy

#crm_mon

============

Lastupdated:ThuAug922:36:182012

Stack:openais

CurrentDC:node1.7ing.com-partitionwithquorum

Version:1.1.5-1.1.el5-

2Nodesconfigured,2expectedvotes

3Resourcesconfigured.

============

Nodenode1.7ing.com:standby

Online:[node2.7ing.com]

nfs(ocf::heartbeat:Filesystem):Startednode2.7ing.com

vip(ocf::heartbeat:IPaddr):Startednode2.7ing.com

mysqld(lsb:mysqld):Startednode2.7ing.com