mysql資料庫常規協議,mysql用的什麼協議

本文目錄一覽：

• 1、mysql 核心內容-上
• 2、訪問伺服器mysql資料庫，ssh登陸，分別使用的是什麼協議？
• 3、五大常見的MySQL高可用方案(最全)
• 4、遵守gpl協議的mysql資料庫 甲骨文是否有權收費
• 5、MySQL與Redis資料庫連接池介紹（圖示+源碼+代碼演示）
• 6、如何處理mysql資料庫並發更新問題

mysql 核心內容-上

1、SQL語句執行流程

MySQL大體上可分為Server層和存儲引擎層兩部分。

Server層：

連接器：TCP握手後伺服器來驗證登陸用戶身份，A用戶創建連接後，管理員對A用戶許可權修改了也不會影響到已經創建的鏈接許可權，必須重新登陸。

查詢緩存：查詢後的結果存儲位置，MySQL8.0版本以後已經取消，因為查詢緩存失效太頻繁，得不償失。

分析器：根據語法規則，判斷你輸入的這個SQL語句是否滿足MySQL語法。

優化器：多種執行策略可實現目標，系統自動選擇最優進行執行。

執行器：判斷是否有許可權，將最終任務提交到存儲引擎。

存儲引擎層

負責數據的存儲和提取。其架構模式是插件式的，支持InnoDB、MyISAM、Memory等多個存儲引擎。現在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認存儲引擎(經常用的也是這個)。

SQL執行順序

2、BinLog、RedoLog、UndoLog

BinLog

BinLog是記錄所有資料庫表結構變更（例如create、alter table）以及表數據修改(insert、update、delete)的二進位日誌，主從資料庫同步用到的都是BinLog文件。BinLog日誌文件有三種模式。

STATEMENT 模式

內容：binlog 記錄可能引起數據變更的 sql 語句

優勢：該模式下，因為沒有記錄實際的數據，所以日誌量很少 IO 都消耗很低，性能是最優的

劣勢：但有些操作並不是確定的，比如 uuid() 函數會隨機產生唯一標識，當依賴 binlog 回放時，該操作生成的數據與原數據必然是不同的，此時可能造成無法預料的後果。

ROW 模式

內容：在該模式下，binlog 會記錄每次操作的源數據與修改後的目標數據，StreamSets就要求該模式。

優勢：可以絕對精準的還原，從而保證了數據的安全與可靠，並且複製和數據恢復過程可以是並發進行的

劣勢：缺點在於 binlog 體積會非常大，同時，對於修改記錄多、欄位長度大的操作來說，記錄時性能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取數據。

MIXED 模式

內容：是對上述STATEMENT 跟 ROW 兩種模式的混合使用。

細節：對於絕大部分操作，都是使用 STATEMENT 來進行 binlog 沒有記錄，只有以下操作使用 ROW 來實現：表的存儲引擎為 NDB，使用了uuid() 等不確定函數，使用了 insert delay 語句，使用了臨時表

主從同步流程：

1、主節點必須啟用二進位日誌，記錄任何修改了資料庫數據的事件。

2、從節點開啟一個線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協議，請求主節點的二進位日誌文件中的事件 。

3、主節點啟動一個線程（dump Thread），檢查自己二進位日誌中的事件，跟對方請求的位置對比，如果不帶請求位置參數，則主節點就會從第一個日誌文件中的第一個事件一個一個發送給從節點。

4、從節點接收到主節點發送過來的數據把它放置到中繼日誌（Relay log）文件中。並記錄該次請求到主節點的具體哪一個二進位日誌文件內部的哪一個位置（主節點中的二進位文件會有多個）。

5、從節點啟動另外一個線程（sql Thread ），把 Relay log 中的事件讀取出來，並在本地再執行一次。

mysql默認的複製方式是非同步的，並且複製的時候是有並行複製能力的。主庫把日誌發送給從庫後不管了，這樣會產生一個問題就是假設主庫掛了，從庫處理失敗了，這時候從庫升為主庫後，日誌就丟失了。由此產生兩個概念。

全同步複製

主庫寫入binlog後強制同步日誌到從庫，所有的從庫都執行完成後才返回給客戶端，但是很顯然這個方式的話性能會受到嚴重影響。

半同步複製

半同步複製的邏輯是這樣，從庫寫入日誌成功後返回ACK確認給主庫，主庫收到至少一個從庫的確認就認為寫操作完成。

還可以延伸到由於主從配置不一樣、主庫大事務、從庫壓力過大、網路震蕩等造成主備延遲，如何避免這個問題？主備切換的時候用可靠性優先原則還是可用性優先原則？如何判斷主庫Crash了？互為主備的情況下如何避免主備循環複製？被刪庫跑路了如何正確恢復？( o )… 感覺越來越扯到DBA的活兒上去了。

RedoLog

可以先通過下面demo理解：

飯點記賬可以把賬單寫在賬本上也可以寫在粉板上。有人賒賬或者還賬的話，一般有兩種做法：

1、直接把賬本翻出來，把這次賒的賬加上去或者扣除掉。

2、先在粉板上記下這次的賬，等打烊以後再把賬本翻出來核算。

生意忙時選後者，因為前者太麻煩了。得在密密麻麻的記錄中找到這個人的賒賬總額信息，找到之後再拿出算盤計算，最後再將結果寫回到賬本上。

同樣在MySQL中如果每一次的更新操作都需要寫進磁碟，然後磁碟也要找到對應的那條記錄，然後再更新，整個過程IO成本、查找成本都很高。而粉板和賬本配合的整個過程就是MySQL用到的是Write-Ahead Logging 技術，它的關鍵點就是先寫日誌，再寫磁碟。此時賬本 = BinLog，粉板 = RedoLog。

1、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（粉板）裡面，並更新內存。同時，InnoDB引擎會在空閑時將這個操作記錄更新到磁碟裡面。

2、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分數據寫到磁碟，然後擦除RedoLog部分數據。RedoLog類似轉盤。

RedoLog有write pos 跟checkpoint

write pos ：是當前記錄的位置，一邊寫一邊後移，寫到第3號文件末尾後就回到0號文件開頭。

check point：是當前要擦除的位置，也是往後推移並且循環的，擦除記錄前要把記錄更新到數據文件。

write pos和check point之間的是粉板上還空著的部分，可以用來記錄新的操作。如果write pos追上checkpoint，表示粉板滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint推進一下。

有了redo log，InnoDB就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。 redolog兩階段提交：為了讓binlog跟redolog兩份日誌之間的邏輯一致。提交流程大致如下：

1 prepare階段 — 2 寫binlog — 3 commit

當在2之前崩潰時，重啟恢復後發現沒有commit，回滾。備份恢復：沒有binlog 。一致

當在3之前崩潰時，重啟恢複發現雖沒有commit，但滿足prepare和binlog完整，所以重啟後會自動commit。備份：有binlog. 一致

binlog跟redolog區別：

redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現的，所有引擎都可以使用。

redo log是物理日誌，記錄的是在某個數據頁上做了什麼修改；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c欄位加1。

redo log是循環寫的，空間固定會用完；binlog是可以追加寫入的。追加寫是指binlog文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。

UndoLog

UndoLog 一般是邏輯日誌，主要分為兩種：

insert undo log

代表事務在insert新記錄時產生的undo log, 只在事務回滾時需要，並且在事務提交後可以被立即丟棄

update undo log

事務在進行update或delete時產生的undo log; 不僅在事務回滾時需要，在快照讀時也需要；所以不能隨便刪除，只有在快速讀或事務回滾不涉及該日誌時，對應的日誌才會被purge線程統一清除

3、MySQL中的索引

索引的常見模型有哈希表、有序數組和搜索樹。

哈希表：一種以KV存儲數據的結構，只適合等值查詢，不適合範圍查詢。

有序數組：只適用於靜態存儲引擎，涉及到插入的時候比較麻煩。可以參考Java中的ArrayList。

搜索樹：按照數據結構中的二叉樹來存儲數據，不過此時是N叉樹(B+樹)。廣泛應用在存儲引擎層中。

B+樹比B樹優勢在於：

B+ 樹非葉子節點存儲的只是索引，可以存儲的更多。B+樹比B樹更加矮胖，IO次數更少。

B+ 樹葉子節點前後管理，更加方便範圍查詢。同時結果都在葉子節點，查詢效率穩定。

B+樹中更有利於對數據掃描，可以避免B樹的回溯掃描。

索引的優點：

1、唯一索引可以保證每一行數據的唯一性

2、提高查詢速度

3、加速表與表的連接

4、顯著的減少查詢中分組和排序的時間

5、通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。

索引的缺點：

1、創建跟維護都需要耗時

2、創建索引時，需要對錶加鎖，在鎖表的同時，可能會影響到其他的數據操作

3、 索引需要磁碟的空間進行存儲，磁碟佔用也很快。

4、當對表中的數據進行CRUD的時，也會觸發索引的維護，而維護索引需要時間，可能會降低數據操作性能

索引設計的原則不應該：

1、索引不是越多越好。索引太多，維護索引需要時間跟空間。

2、 頻繁更新的數據，不宜建索引。

3、數據量小的表沒必要建立索引。

應該：

1、重複率小的列建議生成索引。因為重複數據少，索引樹查詢更有效率，等價基數越大越好。

2、數據具有唯一性，建議生成唯一性索引。在資料庫的層面，保證數據正確性

3、頻繁group by、order by的列建議生成索引。可以大幅提高分組和排序效率

4、經常用於查詢條件的欄位建議生成索引。通過索引查詢，速度更快

索引失效的場景

1、模糊搜索：左模糊或全模糊都會導致索引失效，比如’%a’和’%a%’。但是右模糊是可以利用索引的，比如’a%’ 。

2、隱式類型轉換：比如select * from t where name = xxx , name是字元串類型，但是沒有加引號，所以是由MySQL隱式轉換的，所以會讓索引失效 3、當語句中帶有or的時候：比如select * from t where name=『sw』 or age=14

4、不符合聯合索引的最左前綴匹配：(A,B,C)的聯合索引，你只where了C或B或只有B,C

關於索引的知識點：

主鍵索引：主鍵索引的葉子節點存的是整行數據信息。在InnoDB里，主鍵索引也被稱為聚簇索引（clustered index）。主鍵自增是無法保證完全自增的哦，遇到唯一鍵衝突、事務回滾等都可能導致不連續。

唯一索引：以唯一列生成的索引，該列不允許有重複值，但允許有空值(NULL)

普通索引跟唯一索引查詢性能：InnoDB的數據是按數據頁為單位來讀寫的，默認每頁16KB，因此這兩種索引查詢數據性能差別微乎其微。

change buffer：普通索引用在更新過程的加速，更新的欄位如果在緩存中，如果是普通索引則直接更新即可。如果是唯一索引需要將所有數據讀入內存來確保不違背唯一性，所以盡量用普通索引。

非主鍵索引：非主鍵索引的葉子節點內容是主鍵的值。在InnoDB里，非主鍵索引也被稱為二級索引（secondary index）

回表：先通過資料庫索引掃描出數據所在的行，再通過行主鍵id取出索引中未提供的數據，即基於非主鍵索引的查詢需要多掃描一棵索引樹。

覆蓋索引：如果一個索引包含（或者說覆蓋）所有需要查詢的欄位的值，我們就稱之為覆蓋索引。

聯合索引：相對單列索引，組合索引是用多個列組合構建的索引，一次性最多聯合16個。

最左前綴原則：對多個欄位同時建立的組合索引(有順序，ABC，ACB是完全不同的兩種聯合索引) 以聯合索引(a,b,c)為例，建立這樣的索引相當於建立了索引a、ab、abc三個索引。另外組合索引實際還是一個索引，並非真的創建了多個索引，只是產生的效果等價於產生多個索引。

索引下推：MySQL 5.6引入了索引下推優化，可以在索引遍歷過程中，對索引中包含的欄位先做判斷，過濾掉不符合條件的記錄，減少回表字數。

索引維護：B+樹為了維護索引有序性涉及到頁分裂跟頁合併。增刪數據時需考慮頁空間利用率。

自增主鍵：一般會建立與業務無關的自增主鍵，不會觸發葉子節點分裂。

延遲關聯：通過使用覆蓋索引查詢返回需要的主鍵，再根據主鍵關聯原表獲得需要的數據。

InnoDB存儲: * .frm文件是一份定義文件，也就是定義資料庫表是一張怎麼樣的表。*.ibd文件則是該表的索引，數據存儲文件，既該表的所有索引樹，所有行記錄數據都存儲在該文件中。

MyISAM存儲：* .frm文件是一份定義文件，也就是定義資料庫表是一張怎麼樣的表。* .MYD文件是MyISAM存儲引擎表的所有行數據的文件。* .MYI文件存放的是MyISAM存儲引擎表的索引相關數據的文件。MyISAM引擎下，表數據和表索引數據是分開存儲的。

MyISAM查詢：在MyISAM下，主鍵索引和輔助鍵索引都屬於非聚簇索引。查詢不管是走主鍵索引，還是非主鍵索引，在葉子結點得到的都是目的數據的地址，還需要通過該地址，才能在數據文件中找到目的數據。

PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引

4、SQL事務隔離級別

ACID的四個特性

原子性（Atomicity）：把多個操作放到一個事務中，保證這些操作要麼都成功，要麼都不成功

一致性（Consistency）：理解成一串對數據進行操作的程序執行下來，不會對數據產生不好的影響，比如憑空產生，或消失

隔離性（Isolation，又稱獨立性）：隔離性的意思就是多個事務之間互相不干擾，即使是並發事務的情況下，他們只是兩個並發執行沒有交集，互不影響的東西；當然實現中，也不一定需要這麼完整隔離性，即不一定需要這麼的互不干擾，有時候還是允許有部分干擾的。所以MySQL可以支持4種事務隔離性

持久性（Durability）：當某個操作操作完畢了，那麼結果就是這樣了，並且這個操作會持久化到日誌記錄中

PS：ACID中C與CAP定理中C的區別

ACID的C著重強調單資料庫事務操作時，要保證數據的完整和正確性，數據不會憑空消失跟增加。CAP 理論中的C指的是對一個數據多個備份的讀寫一致性

事務操作可能會出現的數據問題

1、臟讀(dirty read)：B事務更改數據還未提交，A事務已經看到並且用了。B事務如果回滾，則A事務做錯了

2、 不可重複讀(non-repeatable read)：不可重複讀的重點是修改: 同樣的條件, 你讀取過的數據, 再次讀取出來發現值不一樣了，只需要鎖住滿足條件的記錄

3、 幻讀(phantom read)：事務A先修改了某個表的所有紀錄的狀態欄位為已處理，未提交；事務B也在此時新增了一條未處理的記錄，並提交了；事務A隨後查詢記錄，卻發現有一條記錄是未處理的造成幻讀現象，幻讀僅專指新插入的行。幻讀會造成語義上的問題跟數據一致性問題。

4、 在可重複讀RR隔離級別下，普通查詢是快照讀，是不會看到別的事務插入的數據的。因此，幻讀在當前讀下才會出現。要用間隙鎖解決此問題。

在說隔離級別之前，你首先要知道，你隔離得越嚴實，效率就會越低。因此很多時候，我們都要在二者之間尋找一個平衡點。SQL標準的事務隔離級別由低到高如下： 上圖從上到下的模式會導致系統的並行性能依次降低，安全性依次提高。

讀未提交：別人改數據的事務尚未提交，我在我的事務中也能讀到。

讀已提交(Oracle默認)：別人改數據的事務已經提交，我在我的事務中才能讀到。

可重複讀(MySQL默認)：別人改數據的事務已經提交，我在我的事務中也不去讀，以此保證重複讀一致性。

串列：我的事務尚未提交，別人就別想改數據。

標準跟實現：上面都是關於事務的標準，但是每一種資料庫都有不同的實現，比如MySQL InnDB 默認為RR級別，但是不會出現幻讀。因為當事務A更新了所有記錄的某個欄位，此時事務A會獲得對這個表的表鎖，因為事務A還沒有提交，所以事務A獲得的鎖沒有釋放，此時事務B在該表插入新記錄，會因為無法獲得該表的鎖，則導致插入操作被阻塞。只有事務A提交了事務後，釋放了鎖，事務B才能進行接下去的操作。所以可以說 MySQL的RR級別的隔離是已經實現解決了臟讀，不可重複讀和幻讀的。

5、MySQL中的鎖

無論是Java的並發編程還是資料庫的並發操作都會涉及到鎖，研發人員引入了悲觀鎖跟樂觀鎖這樣一種鎖的設計思想。

悲觀鎖：

優點：適合在寫多讀少的並發環境中使用，雖然無法維持非常高的性能，但是在樂觀鎖無法提更好的性能前提下，可以做到數據的安全性

缺點：加鎖會增加系統開銷，雖然能保證數據的安全，但數據處理吞吐量低，不適合在讀書寫少的場合下使用

樂觀鎖：

優點：在讀多寫少的並發場景下，可以避免資料庫加鎖的開銷，提高DAO層的響應性能，很多情況下ORM工具都有帶有樂觀鎖的實現，所以這些方法不一定需要我們人為的去實現。

缺點：在寫多讀少的並發場景下，即在寫操作競爭激烈的情況下，會導致CAS多次重試，衝突頻率過高，導致開銷比悲觀鎖更高。

實現：資料庫層面的樂觀鎖其實跟CAS思想類似， 通數據版本號或者時間戳也可以實現。

資料庫並發場景主要有三種：

讀-讀：不存在任何問題，也不需要並發控制

讀-寫：有隔離性問題，可能遇到臟讀，幻讀，不可重複讀

寫-寫：可能存更新丟失問題，比如第一類更新丟失，第二類更新丟失

兩類更新丟失問題：

第一類更新丟失：事務A的事務回滾覆蓋了事務B已提交的結果 第二類更新丟失：事務A的提交覆蓋了事務B已提交的結果

為了合理貫徹落實鎖的思想，MySQL中引入了雜七雜八的各種鎖：

鎖分類

MySQL支持三種層級的鎖定，分別為

表級鎖定

MySQL中鎖定粒度最大的一種鎖，最常使用的MYISAM與INNODB都支持表級鎖定。

頁級鎖定

是MySQL中鎖定粒度介於行級鎖和表級鎖中間的一種鎖，表級鎖速度快，但衝突多，行級衝突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。

行級鎖定

Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少資料庫操作的衝突。其加鎖粒度最小，但加鎖的開銷也最大行級鎖不一定比表級鎖要好：鎖的粒度越細，代價越高，相比表級鎖在表的頭部直接加鎖，行級鎖還要掃描找到對應的行對其上鎖，這樣的代價其實是比較高的，所以表鎖和行鎖各有所長。

MyISAM中的鎖

雖然MySQL支持表，頁，行三級鎖定，但MyISAM存儲引擎只支持表鎖。所以MyISAM的加鎖相對比較開銷低，但數據操作的並發性能相對就不高。但如果寫操作都是尾插入，那還是可以支持一定程度的讀寫並發

從MyISAM所支持的鎖中也可以看出，MyISAM是一個支持讀讀並發，但不支持通用讀寫並發，寫寫並發的資料庫引擎，所以它更適合用於讀多寫少的應用場合，一般工程中也用的較少。

InnoDB中的鎖

該模式下支持的鎖實在是太多了，具體如下：

共享鎖和排他鎖 (Shared and Exclusive Locks)

意向鎖（Intention Locks）

記錄鎖（Record Locks）

間隙鎖（Gap Locks）

臨鍵鎖 （Next-Key Locks）

插入意向鎖（Insert Intention Locks）

主鍵自增鎖 (AUTO-INC Locks)

空間索引斷言鎖（Predicate Locks for Spatial Indexes）

舉個栗子，比如行鎖里的共享鎖跟排它鎖：lock in share modle 共享讀鎖：

為了確保自己查到的數據沒有被其他的事務正在修改，也就是說確保查到的數據是最新的數據，並且不允許其他人來修改數據。但是自己不一定能夠修改數據，因為有可能其他的事務也對這些數據使用了 in share mode 的方式上了S 鎖。如果不及時的commit 或者rollback 也可能會造成大量的事務等待。

for update排它寫鎖:

為了讓自己查到的數據確保是最新數據，並且查到後的數據只允許自己來修改的時候，需要用到for update。相當於一個 update 語句。在業務繁忙的情況下，如果事務沒有及時的commit或者rollback 可能會造成其他事務長時間的等待，從而影響資料庫的並發使用效率。

Gap Lock間隙鎖：

1、行鎖只能鎖住行，如果在記錄之間的間隙插入數據就無法解決了，因此MySQL引入了間隙鎖(Gap Lock)。間隙鎖是左右開區間。間隙鎖之間不會衝突。

2、間隙鎖和行鎖合稱NextKeyLock，每個NextKeyLock是前開後閉區間。

間隙鎖加鎖原則(學完忘那種)：

1、加鎖的基本單位是 NextKeyLock，是前開後閉區間。

2、查找過程中訪問到的對象才會加鎖。

3、索引上的等值查詢，給唯一索引加鎖的時候，NextKeyLock退化為行鎖。

4、索引上的等值查詢，向右遍歷時且最後一個值不滿足等值條件的時候，NextKeyLock退化為間隙鎖。

5、唯一索引上的範圍查詢會訪問到不滿足條件的第一個值為止。

訪問伺服器mysql資料庫，ssh登陸，分別使用的是什麼協議？

訪問網頁伺服器是HTTP協議，mysql資料庫用的是tcp/ip協議 ssh登錄用的ssh協議

五大常見的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高可用問題可以被更好的解決。

遵守gpl協議的mysql資料庫 甲骨文是否有權收費

MySQL 遵守的不只是 GPL 協議，而是雙授權模式（dual license）[8] 即你在遵守 GPL 協議的開源項目使用 MySQL，需要遵守 GPL 協議方能使用。如果你在非開源項目使用（即軟體不打算開放源代碼），且該軟體用來銷售，則需要向 MySQL 支付相應 license 費用。[9]

MySQL與Redis資料庫連接池介紹（圖示+源碼+代碼演示）

資料庫連接池（Connection pooling）是程序啟動時建立足夠的資料庫連接，並將這些連接組成一個連接池，由程序動態地對池中的連接進行申請，使用，釋放。

簡單的說：創建資料庫連接是一個很耗時的操作，也容易對資料庫造成安全隱患。所以，在程序初始化的時候，集中創建多個資料庫連接，並把他們集中管理，供程序使用，可以保證較快的資料庫讀寫速度，還更加安全可靠。

不使用資料庫連接池

如果不使用資料庫連接池，對於每一次SQL操作，都要走一遍下面完整的流程：

1.TCP建立連接的三次握手（客戶端與 MySQL伺服器的連接基於TCP協議）

2.MySQL認證的三次我收

3.真正的SQL執行

4.MySQL的關閉

5.TCP的四次握手關閉

可以看出來，為了執行一條SQL，需要進行大量的初始化與關閉操作

使用資料庫連接池

如果使用資料庫連接池，那麼會 事先申請（初始化）好 相關的資料庫連接，然後在之後的SQL操作中會復用這些資料庫連接，操作結束之後資料庫也不會斷開連接，而是將資料庫對象放回到資料庫連接池中

資源重用：由於資料庫連接得到重用，避免了頻繁的創建、釋放連接引起的性能開銷，在減少系統消耗的基礎上，另一方面也增進了系統運行環境的平穩性（減少內存碎片以及資料庫臨時進程/線程的數量）。

更快的系統響應速度：資料庫連接池在初始化過程中，往往已經創建了若干資料庫連接置於池中備用。 此時連接的初始化工作均已完成。對於業務請求處理而言，直接利用現有可用連接，避免了從資料庫連接初始化和釋放過程的開銷，從而縮減了系統整體響應時間。

統一的連接管理，避免資料庫連接泄露：在較為完備的資料庫連接池實現中，可根據預先的連接佔用超時設定，強制收回被佔用連接。從而避免了常規資料庫連接操作中可能出現的資源泄露。

如果說你的伺服器CPU是4核i7的，連接池大小應該為((4*2)+1)=9

相關視頻推薦

90分鐘搞懂資料庫連接池技術|linux後台開發

《tcp/ip詳解卷一》： 150行代碼拉開協議棧實現的篇章

學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂

需要C/C++ Linux伺服器架構師學習資料加qun 812855908 獲取（資料包括 C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg 等），免費分享

源碼下載

下載方式：（Github中下載）

db_pool目錄下有兩個目錄，mysql_pool目錄為MySQL連接池代碼，redis_pool為redis連接池代碼

下面介紹mysql_pool

CDBConn解析

概念： 代表一個數據連接對象實例

相關成員：

m_pDBPool：該資料庫連接對象所屬的資料庫連接池

構造函數： 綁定自己所屬於哪個資料庫連接池

Init()函數： 創建資料庫連接句柄

CDBPool解析

概念：代表一個資料庫連接池

相關成員：

Init()函數：常見指定數量的資料庫實例句柄，然後添加到m_free_list中，供後面使用

GetDBConn()函數： 用於從空閑隊列中返回可以使用的資料庫連接句柄

RelDBConn()函數： 程序使用完該資料庫句柄之後，將句柄放回到空閑隊列中

測試之前，將代碼中的資料庫地址、埠、賬號密碼等改為自己的（代碼中有好幾處）

進入MySQL， 創建mysql_pool_test資料庫

進入到mysql_pool目錄下， 創建一個build目錄並進入 ：

然後輸入如下的命令進行編譯

之後就會在目錄下生成如下的可執行文件

輸入如下兩條命令進行測試： 可以看到不使用資料庫連接池，整個操作耗時4秒左右；使用連接池之後，整個操作耗時2秒左右，提升了一倍

源碼下載

下面介紹redis_pool

測試

進入到redis_pool目錄下， 創建一個build目錄並進入 ：

然後輸入如下的命令進行編譯

之後就會在目錄下生成如下的可執行文件

輸入如下的命令進行測試： 可以看到不使用資料庫連接池，整個操作耗時182ms；使用連接池之後，整個操作耗時21ms，提升了很多

進入redis，可以看到我們新建的key：

如何處理mysql資料庫並發更新問題

現象

Sysbench對MySQL進行壓測, 並發數過大(5k)時, Sysbench建立連接的步驟會超時.

猜想

猜想: 直覺上這很簡單, Sysbench每建立一個連接, 都要消耗一個線程, 資源消耗過大導致超時.

驗證: 修改Sysbench源碼, 調大超時時間, 仍然會發生超時.

檢查環境

猜想失敗, 回到常規的環境檢查:

MySQL error log 未見異常.

syslog 未見異常.

tcpdump 觀察網路包未見異常, 連接能完成正常的三次握手; 只觀察到在出問題的連接中, 有一部分的TCP握手的第一個SYN包發生了重傳, 另一部分沒有發生重傳.

自己寫一個簡單的並發發生器, 替換sysbench, 可重現場景. 排除sysbench的影響

猜想2

懷疑 MySQL 在應用層因為某種原因, 沒有發送握手包, 比如卡在某一個流程上:

檢查MySQL堆棧未見異常, 彷彿MySQL在應用層沒有看到新連接進入.

通過strace檢查MySQL, 發現 accept() 調用確實沒有感知到新連接.

懷疑是OS的原因, Google之, 得到參考文檔: A TCP 「stuck」 connection mystery【】

分析

參考文檔中的現象跟目前的狀況很類似, 簡述如下:

正常的TCP連接流程:

Client 向 Server 發起連接請求, 發送SYN.

Server 預留連接資源, 向 Client 回復SYN-ACK.

Client 向 Server 回復ACK.

Server 收到 ACK, 連接建立.

在業務層上, Client和Server間進行通訊.

當發生類似SYN-flood的現象時, TCP連接的流程會使用SYN-cookie, 變為:

Client 向 Server 發起連接請求, 發送SYN.

Server 不預留連接資源, 向 Client 回復SYN-ACK, 包中附帶有簽名A.

Client 向 Server 回復ACK, 附帶 f(簽名A) (對簽名進行運算的結果).

Server 驗證簽名, 分配連接資源, 連接建立.

在業務層上, Client和Server間進行通訊.

當啟用SYN-cookie時, 第3步的ACK包因為 某種原因 丟失, 那麼:

從Client的視角, 連接已經建立.

從Server的視角, 連接並不存在, 既沒有建立, 也沒有」即將建立」 (若不啟用SYN-cookie, Server會知道某個連接」即將建立」)

發生這種情況時:

若業務層的第一個包應是從 Client 發往 Server, 則會進行重發或拋出連接錯誤

若業務層的第一個包應是從 Server 發往 Client的, Server不會發出第一個包. MySQL的故障就屬於這種情況.

TCP握手的第三步ACK包為什麼丟失

參考文檔中, 對於TCP握手的第三步ACK包的丟失原因, 描述為:

Some of these packets get lost because some buffer somewhere overflows.

我們可以通過Systemtap進一步探究原因. 通過一個簡單的腳本:

probe kernel.function(“cookie_v4_check”).return

{

source_port = @cast($skb-head + $skb-transport_header, “struct tcphdr”)-source

printf(“source=%d, return=%d\n”,readable_port(source_port), $return)

}

function readable_port(port) {

return (port ((19)-1)) 8 | (port 8)

}

觀察結果, 可以確認cookie_v4_check (syn cookie機制進行包簽名檢查的函數)會返回 NULL(0). 即驗證是由於syn cookie驗證不通過, 導致TCP握手的第三步ACK包不被接受.

之後就是對其中不同條件進行觀察, 看看是哪個條件不通過. 最終原因是accept隊列滿(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock  *sk){   return sk-sk_ack_backlog sk-   sk_max_ack_backlog;}

恢復故障與日誌的正關聯

在故障處理的一開始, 我們就檢查了syslog, 結論是未見異常.

當整個故障分析完成, 得知了故障與syn cookie有關, 回頭看syslog, 裡面是有相關的信息, 只是和故障發生的時間不匹配, 沒有正關聯, 因此被忽略.

檢查Linux源碼:

if (!queue-synflood_warned

sysctl_tcp_syncookies != 2

xchg(queue-synflood_warned, 1) == 0)

pr_info(“%s: Possible SYN flooding on port %d. %s.

Check SNMP counters.\n”,

proto, ntohs(tcp_hdr(skb)-dest), msg);

可以看到日誌受到了抑制, 因此日誌與故障的正關聯被破壞.

粗看源碼, 每個listen socket只會發送一次告警日誌, 要獲得日誌與故障的正關聯, 必須每次測試重啟MySQL.

解決方案

這種故障一旦形成, 難以檢測; 系統日誌中只會出現一次, 在下次重啟MySQL之前就不會再出現了; Client如果沒有合適的超時機制, 萬劫不復.

解決方案:

1. 修改MySQL的協議, 讓Client先發握手包. 顯然不現實.

2. 關閉syn_cookie. 有安全的人又要跳出來了.

3. 或者調高syn_cookie的觸發條件 (syn backlog長度). 降低系統對syn flood的敏感度, 使之可以容忍業務的syn波動.

有多個系統參數混合影響syn backlog長度, 參看【】

下圖為精華總結

請點擊輸入圖片描述