mysql服務器宕機,mysql主從宕機恢復

本文目錄一覽：

• 1、mysql主機宕機，從機怎麼啟用？
• 2、如何優化mysql內存佔用高導致宕機
• 3、怎麼查看mysql數據庫中的表是否損壞
• 4、五大常見的MySQL高可用方案(最全)

mysql主機宕機，從機怎麼啟用？

可以手動將應用的數據庫配置修改為從機的配置（ip、port、數據庫名），然後重啟服務。

如何優化mysql內存佔用高導致宕機

1，首先通過任務管理器進行進程排序，查找佔用內存較大的程序進程。一般佔用內存較大的進程有W3WP、sqlserver、mysqld-nt.exe；

2， 站點進程w3wp 可以在cmd命令行中通過 iisapp 命令來對應是那個網站佔用內存較大。可以通過設置回收時間、內存最大使用值或共用進程池來減少內存的佔用，但是如果要保證網站的訪問質量，還是建議升級至更高型號來解決；

3，數據庫 sql server 也可以通過數據庫的企業管理器來設置最大內存佔用，但是如果網站程序必須要佔用較大內存的話，設置後會發生頁面報錯、打不開等問題；

4，MYSQL本身會佔用較大虛擬內存，如果不使用mysql數據庫的話，可以將其停止。

怎麼查看mysql數據庫中的表是否損壞

可以使用語句檢查表。如果結果的msg_text部分是好的，那麼你的表是健康的。反之，則表明mysql數據庫中的表有損壞。另外有些厲害的高手一額可以通過運行腳本來檢測。

MyISAM 表可以採用以下方法進行修復 ：使用 reapair table 或myisamchk 來修復。如果修復無效，採用備份恢復表。

階段1 ：檢查你的表

如果你有很多時間，運行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）選項禁止不必要的信息。如果mysqld 服務器處於宕機狀態，應使用–update-state 選項來告訴myisamchk 將表標記為’ 檢查過的’ 。

你必須只修復那些myisamchk 報告有錯誤的表。對這樣的表，繼續到階段2 。如果在檢查時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。

階段2 ：簡單安全的修復

注釋：如果想更快地進行修復，當運行myisamchk 時，你應將sort_buffer_size 和Key_buffer_size 變量的值設置為可用內存的大約25% 。

首先，試試myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢復模式”) 。這將試圖不接觸數據文件來修復索引文件。如果數據文件包含它應有的一切內容和指向數據文件內正確地點的刪除連接，這應該管用並且表可被修復。開始修復下一張表。否則，執行下列過程：

在繼續前對數據文件進行備份。使用myisamchk -r tbl_name(-r 意味着“ 恢復模式”) 。這將從數據文件中刪除不正確的記錄和已被刪除的記錄並重建索引文件。

如果前面的步驟失敗，使用myisamchk –safe-recover tbl_name 。安全恢復模式使用一個老的恢復方法，處理常規恢復模式不行的少數情況( 但是更慢) 。如果在修復時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。

階段3 ：困難的修復

只有在索引文件的第一個16K 塊被破壞，或包含不正確的信息，或如果索引文件丟失，你才應該到這個階段。在這種情況下，需要創建一個新的索引文件。按如下步驟操做：

把數據文件移到安全的地方。使用表描述文件創建新的( 空) 數據文件和索引文件：

shell mysql db_name

mysql SET AUTOCOMMIT=1;

mysql TRUNCATE TABLE tbl_name;

mysql quit

如果你的MySQL 版本沒有TRUNCATE TABLE ，則使用DELETE FROM tbl_name 。將老的數據文件拷貝到新創建的數據文件之中。回到階段2 。現在myisamchk -r -q 應該工作了。你還可以使用REPAIR TABLE tbl_name USE_FRM ，將自動執行整個程序。

階段4 ：非常困難的修復

只有.frm 描述文件也破壞了，你才應該到達這個階段。這應該從未發生過，因為在表被創建以後，描述文件就不再改變了。

從一個備份恢復描述文件然後回到階段3 。你也可以恢復索引文件然後回到階段2 。對後者，你應該用myisamchk -r 啟動。

如果你沒有進行備份但是確切地知道表是怎樣創建的，在另一個數據庫中創建表的一個拷貝。刪除新的數據文件，然後從其他數據庫將描述文件和索引文件移到破壞的數據庫中。這樣提供了新的描述和索引文件，但是讓.MYD 數據文件獨自留下來了。回到階段2並且嘗試重建索引文件。

五大常見的MySQL高可用方案(最全)

1. 概述

我們在考慮MySQL數據庫的高可用的架構時，主要要考慮如下幾方面：

如果數據庫發生了宕機或者意外中斷等故障，能儘快恢複數據庫的可用性，儘可能的減少停機時間，保證業務不會因為數據庫的故障而中斷。

用作備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。

當業務發生數據庫切換時，切換前後的數據庫內容應當一致，不會因為數據缺失或者數據不一致而影響業務。

關於對高可用的分級在這裡我們不做詳細的討論，這裡只討論常用高可用方案的優缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步複製

使用雙節點數據庫，搭建單向或者雙向的半同步複製。在5.7以後的版本中，由於lossless replication、logical多線程複製等一些列新特性的引入，使得MySQL原生半同步複製更加可靠。

常見架構如下：

通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監控數據庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用數據庫。

優點：

架構比較簡單，使用原生半同步複製作為數據同步的依據；

雙節點，沒有主機宕機後的選主問題，直接切換即可；

雙節點，需求資源少，部署簡單；

缺點：

完全依賴於半同步複製，如果半同步複製退化為異步複製，數據一致性無法得到保證；

需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步複製優化

半同步複製機制是可靠的。如果半同步複製一直是生效的，那麼便可以認為數據是一致的。但是由於網絡波動等一些客觀原因，導致半同步複製發生超時而切換為異步複製，那麼這時便不能保證數據的一致性。所以儘可能的保證半同步複製，便可提高數據的一致性。

該方案同樣使用雙節點架構，但是在原有半同複製的基礎上做了功能上的優化，使半同步複製的機制變得更加可靠。

可參考的優化方案如下：

2.2.1. 雙通道複製

半同步複製由於發生超時後，複製斷開，當再次建立起複制時，同時建立兩條通道，其中一條半同步複製通道從當前位置開始複製，保證從機知道當前主機執行的進度。另外一條異步複製通道開始追補從機落後的數據。當異步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。

2.2.2. binlog文件服務器

搭建兩條半同步複製通道，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步複製發生網絡問題退化後，啟動與文件服務器的半同步複製通道。當主從半同步複製恢復後，關閉與文件服務器的半同步複製通道。

優點：

雙節點，需求資源少，部署簡單；

架構簡單，沒有選主的問題，直接切換即可;

相比於原生複製，優化後的半同步複製更能保證數據的一致性。

缺點：

需要修改內核源碼或者使用mysql通信協議。需要對源碼有一定的了解，並能做一定程度的二次開發。

依舊依賴於半同步複製，沒有從根本上解決數據一致性問題。

2.3. 高可用架構優化

將雙節點數據庫擴展到多節點數據庫，或者多節點數據庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。

由於半同步複製，存在接收到一個從機的成功應答即認為半同步複製成功的特性，所以多從半同步複製的可靠性要優於單從半同步複製的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。

但是由於數據庫數量較多，所以需要數據庫管理軟件來保證數據庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：

2.3.1. MHA+多節點集群

MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。

MHA Node運行在每台MySQL服務器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。

MHA也可以擴展到如下的多節點集群：

優點：

可以進行故障的自動檢測和轉移;

可擴展性較好，可以根據需要擴展MySQL的節點數量和結構;

相比於雙節點的MySQL複製，三節點/多節點的MySQL發生不可用的概率更低

缺點：

至少需要三節點，相對於雙節點需要更多的資源;

邏輯較為複雜，發生故障後排查問題，定位問題更加困難;

數據一致性仍然靠原生半同步複製保證，仍然存在數據不一致的風險;

可能因為網絡分區發生腦裂現象;

2.3.2. zookeeper+proxy

Zookeeper使用分布式算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網絡分區現象的產生。

優點：

較好的保證了整個系統的高可用性，包括proxy、MySQL;

擴展性較好，可以擴展為大規模集群;

缺點：

數據一致性仍然依賴於原生的mysql半同步複製;

引入zk，整個系統的邏輯變得更加複雜;

2.4. 共享存儲

共享存儲實現了數據庫服務器和存儲設備的解耦，不同數據庫之間的數據同步不再依賴於MySQL的原生複製功能，而是通過磁盤數據同步的手段，來保證數據的一致性。

2.4.1. SAN共享儲存

SAN的概念是允許存儲設備和處理器（服務器）之間建立直接的高速網絡（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：

使用共享存儲時，MySQL服務器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

很好的保證數據的強一致性；

不會因為MySQL的邏輯錯誤發生數據不一致的情況；

缺點：

需要考慮共享存儲的高可用；

價格昂貴；

2.4.2. DRBD磁盤複製

DRBD是一種基於軟件、基於網絡的塊複製存儲解決方案，主要用於對服務器之間的磁盤、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁盤時，還會將數據發送到網絡中另一台主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：

當本地主機出現問題，遠程主機上還保留着一份相同的數據，可以繼續使用，保證了數據的安全。

DRBD是linux內核模塊實現的快級別的同步複製技術，可以與SAN達到相同的共享存儲效果。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

相比於SAN儲存網絡，價格低廉；

保證數據的強一致性；

缺點：

對io性能影響較大；

從庫不提供讀操作；

2.5. 分布式協議

分布式協議可以很好解決數據一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現數據庫的高可用性和數據一致性。

優點：

全部使用官方組件，不依賴於第三方軟件；

可以實現數據的強一致性；

缺點：

國內使用的較少；

配置較複雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異；

至少三節點；

2.5.2. Galera

基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：

優點：

多主寫入，無延遲複製，能保證數據強一致性；

有成熟的社區，有互聯網公司在大規模的使用；

自動故障轉移，自動添加、剔除節點；

缺點：

需要為原生MySQL節點打wsrep補丁

只支持innodb儲存引擎

至少三節點；

2.5.3. POAXS

Paxos 算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。這個算法被認為是同類算法中最有效的。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：

優點：

多主寫入，無延遲複製，能保證數據強一致性；

有成熟理論基礎；

自動故障轉移，自動添加、剔除節點；

缺點：

只支持innodb儲存引擎

至少三節點；

3. 總結

隨着人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC算法的引入等等。

而使用分布式算法用來解決MySQL數據庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。

隨着官方MySQL Group Replication的GA，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。