預備知識 ：
1.雙機熱備
對於雙機熱備這一概念，我搜索了很多資料，最後，還是按照大多數資料所講分成廣義與狹義兩種意義來說。
從廣義上講，就是對於重要的服務，使用兩臺服務器，互相備份，共同執行同一服務。當一臺服務器出現故障時，可以由另一臺服務器承擔服務任務，從而在不需要人工干預的情況下，自動保證系統能持續提供服務。
從狹義上講，雙機熱備就是使用互爲備份的兩臺服務器共同執行同一服務，其中一臺主機爲工作機（Primary Server），另一臺主機爲備份主機（Standby Server）。在系統正常情況下，工作機爲應用系統提供服務，備份機監視工作機的運行情況（一般是通過心跳診斷，工作機同時也在檢測備份機是否正常），當工作機出現異常，不能支持應用系統運營時，備份機主動接管工作機的工作，繼續支持關鍵應用服務，保證系統不間斷的運行。雙機熱備針對的是IT核心服務器、存儲、網絡路由交換的故障的高可用性解決方案。
2.爲什麼要進行雙機熱備？
雙機熱備服務針對的是服務器的故障。服務器的故障可能由各種原因引起，如設備故障、操作系統故障、軟件系統故障等等。一般地講，在技術人員在現場的情況下，恢復服務器正常可能需要10分鐘、幾小時甚至幾天。從實際經驗上看，除非是簡單地重啓服務器（可能隱患仍然存在），否則往往需要幾個小時以上。而如果技術人員不在現場，則恢復服務的時間就更長了。
而對於一些重要系統而言，用戶是很難忍受這樣長時間的服務中斷的。因此，就需要通過雙機熱備服務，來避免長時間的服務中斷，保證系統長期、可靠的服務。
當然，決定是否使用雙機熱備，正確的方法是要分析一下系統的重要性以及對服務中斷的容忍程度，以些決定是否使用雙機熱備。換句話說，就是你的用戶能容忍多長時間恢復服務，如果服務不能恢復會造成多大的影響。
在考慮雙機熱備時，需要注意，一般意義上的雙機熱備都會有一個切換過程，這個切換過程可能是一分鐘左右。在切換過程中，服務是有可能短時間中斷的。但是，當切換完成後，服務將正常恢復。因此，雙機熱備不是無縫、不中斷的，但它能夠保證在出現系統故障時，能夠很快恢復正常的服務，業務不致受到影響。而如果沒有雙機熱備，則一旦出現服務器故障，可能會出現幾個小時的服務中斷，對業務的影響就可能會造成很嚴重的損失。
3.雙機熱備技術與備份的概念區別
熱備份指的是：High Available（HA）即高可用，而備份指的是Backup,即數據備份的一種，這是兩種不同的概念，應對的產品也是兩種功能上完全不同的產品。熱備份主要保障業務的連續性，實現的方法是故障點的轉移。而備份，主要目的是爲了防止數據丟失，而做的一份拷貝，所以備份強調的是數據恢復而不是應用的故障轉移。
4.雙機熱備方案的主要兩種組建方式
雙機熱備方案在進行討論的時候一定要考慮到很多的因素，其中在各種環境下應用的時候需要格外的引起注意。當然還是有主要的兩方式可以借鑑考慮的。
第一種，雙機熱備它的工作原理是使用兩臺服務器，一臺作爲主服務器（Active），運行應用系統來提供服務。另一臺作爲備機，安裝完全一樣的應用系統，但處於待機狀態（Standby）。當Active服務器出現故障時，通過軟件診測將Standby機器激活，保證應用在短時間內完成恢復正常使用。
第二種，雙機互備方式則是在雙機熱備的基礎上，兩個相對獨立的應用在兩臺機器同時運行，但彼此均設爲備機，當某一臺服務器出現故障時，另一臺服務器可以在短時間內將故障服務器的應用接管過來，從而保證了應用的持續性，這種方式實際上是雙機熱備方案的一種應用。
但目前使用最多的還是主從模式的雙機熱備方案。其大致表示可如下圖所示：
目前基於存儲共享的雙機熱備是雙機熱備方案的最標準方案。對於這種方式，採用兩臺服務器，使用共享的存儲設備（磁盤陣列櫃或存儲區域網SAN）。兩臺服務器可以採用主從、互備等不同的方式。在工作過程中，兩臺服務器將以下一個虛擬的IP地址對外提供服務，依工作方式的不同，將服務請求發送給其中一臺服務器承擔。同時，服務器通過心跳線（目前往往採用建立私有網絡的方式）偵測另一臺服務器的工作狀況。
下圖即爲雙機熱備工作大致狀況圖，如下圖所示：
雙機熱備方案當一臺服務器出現故障時，另一臺服務器根據心跳偵測的情況做出判斷，並進行切換，接管服務。對於用戶而言，這一過程是全自動的，在很短時間內完成，從而不會對業務造成大的影響。由於使用共享的存儲設備，因此兩臺服務器使用的實際上是一樣的數據，由雙機或集羣軟件對其進行管理。
5.MySQL雙機熱備實現原理圖
有了上面對雙機熱備知識的講解，對其實現原理就有了一個深入瞭解，那麼我們要做mysql數據庫的雙機熱備就清楚明瞭多了。
Mysql雙機熱備系統的拓撲結構如下圖所示：
兩臺服務器通過以太網連接網絡，通過網絡對外提供服務、相互通信。
兩臺服務器之間用com口直接互聯，雙機熱備軟件利用這個連接進行雙機熱備相關的通信、監控和控制等。
兩臺服務器通過HBA卡連接FC網絡，訪問共同的磁盤陣列，實現雙機熱備系統必要的磁盤。
6.Mysql雙機熱備實現的配置
爲了數據的安全，客戶有兩臺機器作爲互相備份，當一臺機器出現故障時，自動切換到另一臺服務器。大部分的軟件是通過LifeKeeper來實現的，但是Mysql的雙機備份在LifeKeeper裏沒有實現，所以只能自己手動來實現Mysql的雙機備份了。
其實，Mysql的雙機備份有一個很簡單的第三方軟件可以實現，那就是SQLyog，他有一個功能叫sja(SQLyog Job Agent)可以輕鬆實現，但是卻有一個不足之處，就是Mysql表裏必須有一個primary key，即主鍵值，如果沒有，則此表不能用sja來實現。
第二種方法就是用Mysql自身的Replication機制來實現了。但是這個功能只有Mysql 3.23以上的版本纔有。
這裏先說明下，由於我還沒有通過實際的應用例子來檢測這種雙機熱備方式是否能過通過，所以我會在我通過實例實現後在續寫我後面的關於Mysql雙機熱備實現的配置部分。現在這部分內容主要講的還是雙機熱備份的實現原理和意義。
★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'@'218.206.70.146' identified by '123456';
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
找到配置文件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='59.151.15.36',master_user='replicate',master_password='123456',
> 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 status\G;
查看下面兩項值均爲Yes，即表示設置從服務器成功。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
2.4 測試同步
之前開始已經說過了在數據庫test只有一個表tb_mobile沒有數據，我們可以先查看下兩服務器的數據庫是否有數據：
Master:59.151.15.36
Slave:218.206.70.146
好了，現在可以在Master服務器中插入數據看下是否能同步。
Master:59.151.15.36
Slave:218.206.70.146
可以從上面兩個截圖上看出，在Master服務器上進行插入的數據在Slave服務器可以查到，這就表示雙機熱備配置成功了。
3. Mysql 建立主－主服務器雙機熱備配置步驟
服務器還是用回現在這兩臺服務器
3.1創建同步用戶
同時在主從服務器建立一個連接帳戶，該帳戶必須授予REPLIATION SLAVE權限。這裏因爲服務器A和服務器B互爲主從，所以都要分別建立一個同步用戶。
服務器A：
mysql> grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';
mysql> flush privileges;
服務器B：
mysql> grant replication slave on *.* to 'replicate'@'59.151.15.36' identified by '123456';
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='218.206.70.146',master_user='replicate',master_password='123456',
> master_log_file=' mysql-bin.000011 ',master_log_pos=497;
服務器B：
mysql>change master to
>master_host='59.151.15.36',master_user='replicate',master_password='123456',
> master_log_file=' mysql-bin.000016 ',master_log_pos=107;
3.6 分別在A和B服務器上重啓從服務線程
mysql>start slave;
3.7 分別在A和B服務器上查看從服務器狀態
mysql>show slave status\G;
查看下面兩項值均爲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在每Ｎ次binlog寫入後與硬盤同步。當sync_binlog變量設置爲１是最安全的，因爲在crash崩潰的情況下，你的二進制日誌binary log只有可能丟失最多一個語句或者一個事務。但是，這也是最慢的一種方式（除非磁盤有使用帶蓄電池後備電源的緩存cache,使得同步到磁盤的操作非常快）。
即使sync_binlog設置爲１，出現崩潰時，也有可能表內容和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的值被忽略。例如：表內已有一些數據，就會用現在已有的最大自增值做爲初始值。