高性能MySQL讀書筆記 (六)

1. 可擴展的Mysql

可擴展性: 經過增長資源提高容量的能力

1.1 考慮負載

容量能夠簡單地認爲是處理負載的能力,考慮負載可從如下幾個角度

1. 數據量: 不少應用從不物理刪除任何數據,應用所積累的數據量是可擴展的廣泛挑戰

2. 用戶量: 更多的用戶意味着更多的事務,更多的複雜查詢

3. 用戶活躍度

4. 相關數據集的大小

1.2 規劃可擴展性

1. 估算須要承擔的負載到底有多少

2. 大體正確地估計日程表

3. 應用的功能完成多少

4. 預期的最大負載是多少

5. 若是依賴系統的每一個部分分擔負載,某個部分失效時會發生什麼

1.3 向上擴展(垂直擴展)

1. 單臺服務器增長各類高性能硬件

2. 燒錢有效的方法

3. 不該該無限制向上擴展

1.4 向外擴展

1. 策略: 複製,拆分,數據分片

2. 按功能拆分: 常見作法,根據功能將應用部署在不一樣服務器,並使用專用的數據庫服務器

1.4.1 數據分片

數據分片是目前擴展大型MySQL最通用且最成功的方法

1. 應用設計初期考慮到,後期實現就比較容易,不然很難將應用從單一數據存儲轉換爲分片架構

2. 文中舉例: 經過用戶id來對文章和評論進行分片,而將用戶的信息保留在單個節點上

3. 數據庫訪問抽象層,下降應用和分片數據之間通訊的複雜度

4. 如非必要儘可能不分片

5. 數據分片最大的挑戰就是查找和獲取數據

6. 相似於表分區,選擇分區鍵和數據分片方式是關鍵,具體請細查

1.5 經過集羣擴展

1. 可使用集羣或數據庫分佈式技術根據場景適當解決一些問題

2. 書中提到技術: NDB Cluster, Clustrix等技術

1.6 向內擴展

1. 對再也不須要的數據進行歸檔和清理

2. 須要考慮對應用的影響

3. 須要考慮數據邏輯的一致性,例如清理A表歷史數據時須要考慮全部關聯數據的處理

4. 冷熱數據分離

1.7 負載均衡

1.7.1 目的

1. 可擴展性: 如讀寫分離時從備庫讀數據

2. 高效性: 把更多工做分配給更好的機器

3. 可用性: 使用時刻保持可用的服務器

4. 透明性: 客戶端無需知道服務器

5. 一致性: 若是應用是有狀態的,負載均衡器就應該將相關的查詢指向同一個服務器

1.7.2 直接鏈接

1.7.2.1 複製上的讀寫分離

1. 基於查詢分離: 將不能容忍髒數據的查詢分配到主庫,其餘分配到備庫

2. 基於髒數據分離: 讓應用檢查複製延遲,許多報表類應用使用這個策略

3. 基於會話分離: 能夠在會話層作一個標記,若是用戶修改了數據,則一段時間內老是指向主庫

4. 基於版本分離: 給用戶的操做增長版本號,檢查版本號決定從主庫仍是備庫讀取數據

1.7.2.3 修改DNS名

1. 經過變動DNS名指定的服務器實現

2. 缺點不少,不建議

1.7.2.4 轉移IP地址

1. 在服務器之間轉移虛擬地址

2. 給服務器分配固定的ip地址,爲每一個邏輯上的服務使用一個虛擬ip地址

1.7.3 引入中間件

1. 負載均衡器,如HAproxy

2. 負載均衡算法: 隨機, 輪詢,最少鏈接數,最快響應,哈希,權重

3. 服務器池中增長或移除服務器: 在配置鏈接池中的服務器時,要保證有足夠多未使用的容量

2. 高可用性

1. 高可用性意味着更少的宕機時間

2.1 宕機緣由

1. 磁盤空間不足

2. 糟糕的sql或者服務器bug引發

3. 糟糕的表和索引設計

4. 複製問題一般因爲主備數據不一致致使

2.2 高可用性實現

1. 衡量指標: 平均失效時間(MTBF), 平均恢復時間(MTTR)

2. 避免問題: 適當的配置,監控和規範

3. 保證在宕機時能快速恢復,系統製造冗餘,具有故障轉移能力

2.2.1 避免單點失效

1. 經過增長冗餘避免

2. 共享存儲或磁盤複製,若是服務器掛了,備用服務器能夠掛載相同的文件系統執行須要的恢復操做

3. MySQL同步複製

2.2.2 故障轉移和故障恢復

1. 提高備庫或切換角色

2. 虛擬IP地址或IP接管: 當MySQL實例失效時能夠將IP地址轉移到另外一臺MySQL服務器上

3. 使用中間件解決方案

3. 備份與恢復

3.1 設計MySQL備份方案考慮點

1. 在線備份仍是離線備份

2. 邏輯備份仍是物理備份

3. 非顯著數據: 如二進制日誌和InnoDB事務日誌

4. 代碼: 存儲過程,觸發器

5. 服務器配置和複製配置

6. 外部配置,管理腳本

7. 增量備份和差別備份

8. 存儲引擎和數據一致性

3.2 備份數據方式

1. 文件系統中或SAN快照中直接複製數據文件

2. Percona XtraBackup 作熱備份

3.3 InnoDB崩潰恢復

1. 二級索引損壞: 使用OPTIMIZE TABLE修復損壞的二級索引,此外能夠經過構建一個新表重建受影響的索引

2. 聚簇索引損壞: innodb_force_recovery導出表

3. 損壞系統結構: 系統結構包括事務日誌等,可能須要作整個數據庫的導出和還原,由於InnoDB內部絕大部分的工做可能受影響

4. MySQL用戶工具

工欲善其事,必先利其器

4.1 接口工具

1. MySQL Workbench: 一站式的工具

2. SQLyog: 可視化工具之一

4.2 命令行工具集

1. Percona Toolkit

2. MySQL Workbench 工具集

4.3 SQL實用集

1. common_schema

2. MySQL Forge

4.4 監測工具

1. Nagios

2. Zabbix: 同時支持監控和指標收集的完整系統

3. Zenoss: Python寫的

4. Hyperic HQ: 基於Java

4.5 Innotop命令行監控

主要包括如下功能

1. 事務列表

2. 當前運行的查詢

3. 當前鎖和鎖等待列表

4. 服務器狀態和變量彙總信息

5. InnoDB內部信息

6. 複製監控