MySQL數(shù)據(jù)庫技術(shù)體系介紹

1、技術(shù)創(chuàng)新，變革未來MySQL數(shù)據(jù)庫技術(shù)體系介紹01 MySQL簡介與主流分支版本01MySQL 之父Michael “Monty” Widenius1、開源MySQL數(shù)據(jù)庫的創(chuàng)始成員2、MySQL AB公司的首席技術(shù)官3、MySQL數(shù)據(jù)庫第一行代碼的作者4、MySQL數(shù)據(jù)庫命名人5、MariaDB創(chuàng)始人兼首席技術(shù)官；6、獨(dú)自完成撰寫MySQL數(shù)據(jù)庫服務(wù)器端95%的代碼。MySQLMaxDBMariaDB01MySQL 介紹1999成立MySQL AB公司2000公布源碼，采 用GPL協(xié)議， 正式進(jìn)入開源 世界2008.1.16Sun收購 MySQL2019MySQL5.6 MySQL5.7 M

2、ySQL8.0（2016.8.25DMR、2018.4.8 GA）2005.10里程碑，發(fā)布 MySQL5.0，奠 定了邁向高性 能數(shù)據(jù)庫基礎(chǔ)2009.4.20Oracle收購Sun（MySQL5.5）1979 TcX UNIREG1995 Sun Solaris01MySQL 主流分支MySQLEnterprisePercona ServerMariaDBDrizzleMySQL官方MySQL號稱最接近MySQL Enterprise發(fā)行版的 產(chǎn)品XtraDBMonty團(tuán)隊迭代更干凈、快速的MySQL不兼容MySQL01MySQL 行業(yè)前景01全球最大網(wǎng)站Top2001國內(nèi)MySQL行業(yè)應(yīng)用

3、 互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)庫MySQL市場第一 甲骨文公司的兩款數(shù)據(jù)庫（Oracle+MySQL）共占據(jù)著全世界的數(shù)據(jù)庫市場份額的60%以 上，在中國（Oracle+MySQL）的使用更占到80%左右 中國前100個大企業(yè)/國有企業(yè)有99個以上使用Oracle為主MySQL為輔，中國前100個互 聯(lián)網(wǎng)行業(yè)公司有95%以上使用MySQL為主Oracle/NoSQL為輔 MySQL數(shù)據(jù)庫在互聯(lián)網(wǎng)行業(yè)90%以上的使用比例，最典型的就是BAT了，近2年開始MySQL擴(kuò)展到金融、通信、生產(chǎn)制造、快速消費(fèi)品零售、物流運(yùn)輸、醫(yī)療、政府等行業(yè)01MySQL 介紹Oracle VS MySQL ： 企業(yè)服務(wù)軟件的開源與閉

4、源之爭01MySQL 介紹Oracle VS MySQL ： 企業(yè)服務(wù)軟件的開源與閉源之爭Oracle： 功能強(qiáng)大保障體系充分，MOS成熟度高BUG更新較快并發(fā)機(jī)制粒度細(xì)，并發(fā)高軟件成本高運(yùn)維成本依賴數(shù)據(jù)規(guī)模，小規(guī)模數(shù)據(jù)庫 運(yùn)維成本遠(yuǎn)高于MySQL，大規(guī)模數(shù)據(jù)庫 運(yùn)維成高低于MySQL。傳統(tǒng)行業(yè)的霸主技術(shù)掌控度低MySQL：功能略有不足保障體系成熟度不如Oracle BUG更新不如Oracle并發(fā)機(jī)制較粗，比Mongo類NoSQL要強(qiáng)， 并發(fā)性總體不如Oracle軟件成本低運(yùn)維成本依賴數(shù)據(jù)規(guī)模，小規(guī)模數(shù)據(jù)庫 運(yùn)維成本低于Oracle，大規(guī)模數(shù)據(jù)庫運(yùn)維 成高低于Oracle?；ヂ?lián)網(wǎng)行業(yè)技術(shù)掌控度

5、高02 淺談MySQL架構(gòu)05阿里去O的背景淘寶、阿里巴巴B2B和支付寶等公司，98%以上的軟件系統(tǒng)和業(yè)務(wù)都是采用Oracle數(shù)據(jù)庫提供數(shù)據(jù)服務(wù)07年開始阿里巴巴IT開銷史無前例，有著國內(nèi)之最的趨勢，一度成為IBM、Oracle的中國標(biāo)桿客戶09年淘寶更是上了全球排名Top N的大RAC集群，亞洲第一，有20個節(jié)點(diǎn)那么，問題來了，千萬級甚至上億的Oracle產(chǎn)品+服務(wù)無法支撐阿里發(fā)展的速度，how to ？ 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在擴(kuò)展方面沒一家解決得好的 DB層已無法獨(dú)自承載互聯(lián)網(wǎng)社區(qū)業(yè)務(wù)的高速發(fā)展，架構(gòu)開始受到重視 由一家服務(wù)商綁定，風(fēng)險高 阿里選擇MySQL背后主要考慮的是成本，以及開源可以

6、定制05阿里去O的背景05阿里云POLARDB05阿里云POLARDB05熟悉的Oracle/MSSQL基礎(chǔ)架構(gòu)Oracle/MSSQL有哪些常用的架 構(gòu)呢？Oracle/MSSQL架構(gòu)中不同節(jié)點(diǎn) 如何保證數(shù)據(jù)的強(qiáng)一致性？那么，MySQL又有哪些常用的架 構(gòu)呢？05一個原則兩個理論ACID原則CAP理論BASE理論05ACID原則-RDBMS理論基礎(chǔ)05ACID原則-RDBMS理論基礎(chǔ)ACID四大基本特性原子性（Atomicity）：事務(wù)是不可分割的工作單位，事務(wù)中的操作要么都發(fā)生，要么都不發(fā)生。一致性（Consistency）：事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)

7、。一致性的核心一部分是靠原子性實(shí)現(xiàn)，另一部分是邏輯實(shí)現(xiàn)。隔離性（Isolation）：事務(wù)在正確提交之前，不允許把事務(wù)對該數(shù)據(jù)的改變提供給任何其他事務(wù)。四大隔離級別，事務(wù)隔離級別越高，高并發(fā)場景下產(chǎn)生的問題就越少，同時付出的性能消耗也將越大。持久性（Durability）：事務(wù)完成后，對數(shù)據(jù)庫所作的更改便持久的保存在數(shù)據(jù)庫中，并不會被回滾。MySQL默認(rèn)REPEATABLE-READ:可重復(fù)讀Oracle默認(rèn)read committed:讀已提交05CAP理論CAP理論是指一個分布式系統(tǒng)不可能同時很好的滿足強(qiáng)一致性（Consistency）、可用性（Availability）、分區(qū)容錯性（Pa

8、rtition tolerance）這3個要求，通常最多只能同時較好的滿足其中的兩個。強(qiáng)一致性系統(tǒng)在執(zhí)行過某項操作后仍處于一致的狀態(tài)。在分布式系統(tǒng)中，更新操作執(zhí)行成功后所有的用戶都應(yīng) 該讀到最新的值，這樣的系統(tǒng)被認(rèn)為是具有強(qiáng)一致性的。等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本?？捎眯悦恳粋€操作總是能夠在一定的時間內(nèi)返回結(jié)果，一定時間指的是在可以容忍的范圍內(nèi)返回結(jié)果，結(jié)果 可以是成功或者失敗。在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求分區(qū)容錯性指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時（即系統(tǒng)中的一部分節(jié)點(diǎn)和其他節(jié)點(diǎn)進(jìn)行通信）分離的系統(tǒng)也能夠正常運(yùn)行。理解 為在存在網(wǎng)絡(luò)分區(qū)的情況下，仍然可以接受請

9、求。節(jié)點(diǎn)crash或者網(wǎng)絡(luò)分片都不應(yīng)該導(dǎo)致一個分布式系統(tǒng)停止 服務(wù)。05CAP理論CA：單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)。 CP：滿足一致性，分區(qū)容錯的系統(tǒng)，通?？捎眯圆皇翘貏e高AP：滿足可用性，分區(qū)容錯性的系統(tǒng)，通?？赡軐σ恢滦砸蟮?5BASE理論BASE理論是為了解決關(guān)系型數(shù)據(jù)庫強(qiáng)一致性引起的可用性降低而提出的解決方案。核心思想是即使無法做到強(qiáng)一致性，但應(yīng)用可以采用適合的方式達(dá)到最終一致性。BASE理論來源于下列三個特征：基本可用（Basically Available）基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，即保證核心可用。在無法通訊時 選

10、擇可用性。軟狀態(tài)（soft state）軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中一般一份 數(shù)據(jù)至少會有三個副本，允許不同節(jié)點(diǎn)間副本同步的延時就是軟狀態(tài)的體現(xiàn)。用鏡像讀代替強(qiáng)一致性讀。最終一致性（Eventual Consistency）最終一致性是指系統(tǒng)中所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強(qiáng)一致 性相反，最終一致性是弱一致性的一種特殊情況。用異步方式確保完成數(shù)據(jù)更新。思考：BASE與CAP、ACID的區(qū)別和聯(lián)系？05熟悉的MySQL基礎(chǔ)架構(gòu) Distributed Replicated Block Device MySQL R

11、eplication MySQL Group Replication MySQL Innodb Cluster MySQL NDB Cluster Master Master MySQL Master High Availability Galera Cluster for MySQL Percona Xtradb ClusterDRBD、MR、MGR、MIC、MNC、MMM、MHA、MGC、PXC、PhxSQL、AliSQL、DRDS你能說出幾種呢？05DRBD（Distributed Replicated Block Device）構(gòu)成要素DRBD模塊包drbd84-utils、 kmod

12、-drbd84物理/虛擬磁盤（存儲）或者分區(qū)MySQL數(shù)據(jù)庫（軟件安裝于本地）Corosync（集群通信）Pacemaker（資源管理）Crmsh（資源配置，用CRM交互工具實(shí)現(xiàn)）模式單主模式：典型的高可靠性集群方案雙主模式：需要采用共享cluster文件系統(tǒng)， 需要特別配置，drbd8.0之后版本DRBD（Distributed Replicated Block Device），由內(nèi)核模塊及腳本組件構(gòu)成，以組建高可用架構(gòu)。實(shí)現(xiàn)方式， 是用軟件實(shí)現(xiàn)的、無共享的、服務(wù)器之間通過網(wǎng)絡(luò)來鏡像塊設(shè)備內(nèi)容的存儲復(fù)制（ /dev/drbd0 ），可以 將DRBD理解為一種基于網(wǎng)絡(luò)的RAID105DRBD（

13、Distributed Replicated Block Device）優(yōu)勢架構(gòu)簡單，同步模式下，保證數(shù)據(jù)的強(qiáng)一致性無單點(diǎn)故障實(shí)現(xiàn)高可用無集群腦裂（Corosync+Pacemaker來自第三方）劣勢主機(jī)資源未充分利用無法取代備份05MR（ MySQL Replication ）ABABC1.經(jīng)典復(fù)制架構(gòu)，1對1AB2.級聯(lián)復(fù)制3.經(jīng)典復(fù)制架構(gòu)，1對多05MR（ MySQL Replication ）4.雙主復(fù)制ABAB5.雙主級聯(lián)復(fù)制ABC6.雙主循環(huán)復(fù)制05MR（ MySQL Replication ）AB7.多源復(fù)制C05MR（ MySQL Replication ）優(yōu)勢架構(gòu)簡單，無單點(diǎn)

14、故障確保高可用技術(shù)門檻低，運(yùn)維簡單查詢類業(yè)務(wù)可實(shí)現(xiàn)負(fù)載均衡，分擔(dān)主節(jié)點(diǎn)壓力劣勢寫業(yè)務(wù)擴(kuò)展性較差不支持同步復(fù)制，數(shù)據(jù)強(qiáng)一致性較差05MR（ MySQL Replication ）async（Asynchronous Replication，異步）MySQL復(fù)制中傳輸日志的一種模式，叫做異步復(fù)制，MySQL默認(rèn)支持的就是這種模式， 最為通用，在不影響主庫性能的前提下盡可能地保證數(shù)據(jù)的安全。主庫在執(zhí)行完一些事務(wù)后，不知道備庫的進(jìn)度。如果備庫落后，并且此時主庫又出 現(xiàn)Crash（例如宕機(jī)），這時備庫中的數(shù)據(jù)就是不完整的。semi-sync（Semisynchronous Replication，半同步

15、）跟async一樣，是MySQL復(fù)制中傳輸日志的另外一種模式，叫半同步復(fù)制，僅保證事務(wù) 已經(jīng)傳遞到備庫上，但是并不確保已經(jīng)在備庫上執(zhí)行完成了。在MySQL5.5中引入并支持。 在這種模式下數(shù)據(jù)的一致性得到最大保障，但會損失一定的寫入性能。05MR（ MySQL Replication ）異步復(fù)制05MR（ MySQL Replication ）半同步復(fù)制在經(jīng)典的復(fù)制架構(gòu)中，哪一種復(fù)制模式更適合用于部署自動化切換腳本呢？05MR（ MySQL Replication ）利用該架構(gòu)如何實(shí)現(xiàn)對前端的透明？如何實(shí)現(xiàn)高可用？常用的負(fù)載均衡器有哪些？Load BalancerMySQLRouterMySQ

16、L ProxyProxySQLLVSKeepAlivedHAproxyNginxAtlas05MMM（ Master Master MySQL）05MMM（ Master Master MySQL）優(yōu)勢存在雙主節(jié)點(diǎn)，沒有主機(jī)宕機(jī)后的選主問題，直接切換即可架構(gòu)比較簡單，使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù)劣勢完全依賴于半同步復(fù)制，如果半同步復(fù)制退化為異步復(fù)制，數(shù)據(jù)一致性無法得到保證需要額外考慮HAProxy、Keepalived的高可用機(jī)制至少3個節(jié)點(diǎn)05MHA（ Master High Availability ）05MHA（ Master High Availability ）05MHA（

17、Master High Availability ）優(yōu)勢故障自動檢測和轉(zhuǎn)移擴(kuò)展性較好，根據(jù)需要擴(kuò)展MySQL的節(jié)點(diǎn)數(shù)量和結(jié)構(gòu)相比于雙節(jié)點(diǎn)的MySQL復(fù)制，三節(jié)點(diǎn)/多節(jié)點(diǎn)的MySQL發(fā)生不可用的概率更低master crash 不會導(dǎo)致主從數(shù)據(jù)不一致由Perl語言開發(fā)的開源工具劣勢至少需要3個節(jié)點(diǎn)，相對于雙節(jié)點(diǎn)需要更多的資源邏輯較為復(fù)雜，發(fā)生故障后排查問題，定位問題更加困難可能因?yàn)榫W(wǎng)絡(luò)分區(qū)發(fā)生腦裂現(xiàn)象需要基于SSH免認(rèn)證配置，存在一定的安全隱患需要編寫腳本或利用第三方工具來實(shí)現(xiàn)VIP的配置05MGR（MySQL Group Replication）Ref：/doc/refman/5.7/en/g

18、roup-replication-summary.html了解一規(guī)則：分布式先提交獲勝規(guī)則由MySQL基于Paxos所開發(fā)的，基本復(fù)制理念05MGR（MySQL Group Replication）單主模式05MGR（MySQL Group Replication）單主模式05MGR（MySQL Group Replication）多主同步模式05MGR（MySQL Group Replication）多主同步模式05MGR（MySQL Group Replication）（N/2+1）高容錯度05MGR（MySQL Group Replication）優(yōu)勢單主模式，查詢類業(yè)務(wù)可實(shí)現(xiàn)負(fù)載均衡，

19、分擔(dān)主節(jié)點(diǎn)壓力，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性多主模式，多節(jié)點(diǎn)寫入，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性數(shù)據(jù)一致性保障：確保集群中大部分節(jié)點(diǎn)收到日志多節(jié)點(diǎn)寫入支持：多寫模式下支持集群中的所有節(jié)點(diǎn)都可以寫入Fault Tolerance: 確保系統(tǒng)發(fā)生故障（包括腦裂）依然可用，雙寫對系統(tǒng)無影響劣勢只支持Innodb存儲引擎，且每張表一定要有一個主鍵目前一個MGR集群最多支持9個節(jié)點(diǎn)COMMIT可能會導(dǎo)致失敗，類似于快照事務(wù)隔離級別的失敗場景必須打開GTID特性，二進(jìn)制日志格式必須設(shè)置為ROW，用于選主與write set05MNC（ MySQL NDB Cluster ）MySQL Cluster是一

20、個無共享的(shared-nothing)、分布式節(jié)點(diǎn)架構(gòu)的存儲方案，其目的是提供容錯性和高性能。05MNC（ MySQL NDB Cluster ）Data節(jié)點(diǎn)組內(nèi)采用同步復(fù)制，以保證組內(nèi)節(jié)點(diǎn) 的數(shù)據(jù)一致性，通過兩階段提交協(xié)議實(shí)現(xiàn)A： 我 要 提 交 了 ， 發(fā) 送 事 務(wù) 給 B B： 我 準(zhǔn) 備 好 了 ， 并 反 饋 給 A A：好的沒問題，你提交吧，發(fā)送指令給B B： 我 提 交 好 了 ， 并 反 饋 給 A A：報告該事務(wù)提交/回滾，繼續(xù)進(jìn)行下一個事務(wù) 處理同步復(fù)制共需要4次消息傳遞，減慢響應(yīng)時間，消 耗部分性能，數(shù)據(jù)節(jié)點(diǎn)之間是走網(wǎng)絡(luò)的，強(qiáng)烈建 議MySQL Cluster運(yùn)行在

21、千兆以上的局域網(wǎng)內(nèi)。05MNC（ MySQL NDB Cluster ）節(jié)點(diǎn)節(jié)點(diǎn)組分區(qū)數(shù)據(jù)副本05MNC（ MySQL NDB Cluster ）配置冗余，實(shí)現(xiàn)Data節(jié)點(diǎn)高可用05MNC（ MySQL NDB Cluster ）Defining NDB Cluster Data Nodes（管理節(jié)點(diǎn)config.ini）ndbd default NoOfReplicas=2The default value for NoOfReplicas is 2. This is the recommended value for most production environments.ImportantWhile the maximum possible value for this parameter is 4, setting NoOfReplicas to a value greater than 2 is not supported in production.WarningSetting NoOfReplicas to 1