Mysql知識點2

6、主從複製

基於BinLog的Replication

• 速度快
• 從節點只讀
• 異步複製
• 弱一致性（由於複製不一樣步）
• master宕機，slaver不會自動升級成master

適用於價值不高的數據，如日誌、帖子等。

https://www.jianshu.com/p/faf0127f1cb2

 

PXC

• 同步複製（真正意義上的同步） 
• 強一致性
• 任意節點讀寫
• 只支持InnoDB引擎
• 寫入效率取決於最弱的那一臺
• 全部表必須都有主鍵

適用於一致性要求較高的數據，如訂單、帳戶、財務。

首先客戶端先發起一個事務，該事務先在本地執行，執行完成以後就要發起對事務的提交操做了。在提交以前須要將產生的複製寫集廣播出去，而後獲取到一個全局的事務ID號，一併傳送到另外一個節點上面。經過合併數據以後，發現沒有衝突數據，執行apply_cd和commit_cb動做，不然就須要取消這次事務的操做。而當前server節點經過驗證以後，執行提交操做，並返回OK，若是驗證沒經過，則執行回滾。固然在生產中至少要有3個節點的集羣環境，若是其中一個節點沒有驗證經過，出現了數據衝突，那麼此時採起的方式就是講出現不一致的節點踢出集羣環境，並且它本身會執行shutdown命令，自動關機。 

7、數據庫三範式

第一範式：數據庫表中任意字段都是單一屬性的，不可再分。

好比某些數據庫系統中須要用到「地址」這個屬性，原本直接將「地址」屬性設計成一個數據庫表的字段就行。可是若是系統常常會訪問「地址」屬性中的「城市」部分，那麼就非要將「地址」這個屬性從新拆分爲省份、城市、詳細地址等多個部分進行存儲。

第二範式：第二範式在第一範式的基礎之上更進一層。第二範式須要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對複合主鍵而言）。

例若有表：

貨物	供應商ID	供應商	價格	供應商地址
毛巾	01	世紀聯華	10.0	星光道
牙刷	01	世紀聯華	5.0	星光道
毛巾	02	十足	12.0	月光道

可知，這裏的主鍵有貨物和供應商ID，價格和兩個主鍵都有關，但是供應商地址只和供應商ID有依賴關係。那麼不符合第二範式，咱們能夠將其修改成兩張表：

供應商ID	供應商	供應商地址
01	世紀聯華	星光道
02	十足	月光道

貨物	供應商ID	價格
毛巾	01	10.0
牙刷	01	5.0
毛巾	01	12.0

這樣就符合了第二範式要求的表內數據和表內主鍵徹底依賴的關係。

第三範式：第三範式須要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。

好比在設計一個訂單數據表的時候，能夠將客戶編號做爲一個外鍵和訂單表創建相應的關係。而不能夠在訂單表中添加關於客戶其它信息（好比姓名、所屬公司等）的字段。