高性能MySQL讀書筆記 (五)

1. 優化服務器設置

1. MySQL有大量的能夠修改的參數,但不該該隨便修改.應該將更多時間花在schema的優化,索引,查詢設計上
2. 配置文件路徑: 一般在/etc/my.cnf
3. 不建議動態修改變量,由於可能致使意外的反作用
4. 經過基準測試迭代優化
5. 具體配置項設置請參照官網手冊,這裏只說起部分

1.1 配置內存使用

1. 肯定可以使用內存上限
2. 每一個鏈接使用多少內存,如排序緩衝和臨時表
3. 肯定操做系統內存使用量
4. 把剩下的分配給緩存,如InnoDB緩存池

1.2 配置MySQL的I/O行爲

1. 有些配置項影響如何同步數據到磁盤及如何恢復操做,這對性能影響很大,並且表現了性能和數據安全之間的平衡

1.2.1 InnoDB I/O配置

1. 重要配置: InnoDB日誌文件大小,InnoDB怎樣刷新日誌緩衝,InnoDB怎樣執行I/O
2. InnoDB使用日誌減小提交事務時開銷,不用每一個事務提交時把緩衝池的髒塊刷到磁盤中
3. 事務日誌能夠把隨機IO變成順序IO,同時若是發生斷電,InnoDB能夠重放日誌恢復已經提交的事務
4. sync_binlog選項控制MySQL怎麼刷新二進制日誌到磁盤
5. 把二進制日誌放到一個帶有電池保護的寫緩存的RAID卷能夠極大的提高性能

1.2.2 MyISAM的I/O配置

1. 由於MyISAM表每次寫入都會將索引變動刷新到磁盤
2. 批量操做時,經過設置delay_key_write能夠延遲索引寫入,能夠提高性能
3. 配置MyISAM怎樣嘗試從損壞中恢復

1.3 配置MySQL併發

1.3.1 InnoDB併發配置

1. 若是在InnoDB併發方面有問題,解決方案一般是升級服務器
2. innodb_thread_concurrency: 限制一次性能夠有多少線程進入內核(根據實踐取合適值)
3. innodb_thread_sleep_delay: 線程第一次進入內核失敗等的時間,若是還不能進入則放入等待線程隊列
4. innodb_commit_concurrency: 控制有多少線程能夠在同一時間提交
5. 使用線程池限制併發: MariaDB已經實現

1.3.2 MyISAM併發配置

1. concurrency_insert: 配置MyISAM打開併發插入

1.4 其餘

1. 基於工做負載的配置: 利用工具分析並調整配置
2. max_connections: 保證服務器不會因應用程序激增的鏈接而不堪重負
3. 安全和穩定的設置: 感興趣者請自行google
4. 高級InnoDB設置: 感興趣者請自行google
5. InnoDB兩個重要配置: innodb_buffer_pool_size和innodb_log_file_size

2. 複製

MySQL內建的複製功能是構建基於MySQL的大規模,高性能應用的基礎.同時也是高可用性,可擴展性,災難恢復,備份及數據倉庫等工做的基礎

2.1 概述

1. 解決問題: 讓一臺服務器的數據與其餘服務器保持同步.主庫能夠同步到多臺備庫,備庫自己也能夠配置爲另外一臺服務器的主庫
2. 複製原理: 經過在主庫上記錄二進制日誌,在備庫重放日誌的方式實現異步的數據複製
3. 複製方式: 基於行的複製和基於語句的複製
4. 向後兼容: 新版本只能做爲老版本的備庫,反之不行

2.2 用途

1. 數據分佈: 在不一樣地理位置分佈數據備份,能夠隨意中止或開始複製.基於行比基於語句帶寬壓力更大
2. 負載均衡: 將讀操做分佈到多個服務器上
3. 備份: 複製是備份的一項有意義的技術補充
4. 高可用性和故障切換: 避免單點失敗
5. MySQL升級測試: 一種廣泛作法是使用一個更高版本的MySQL做爲備庫保證明例升級前查詢可以在備庫按照預期執行

2.3 過程

1. 主庫把數據更改記錄到二進制日誌(Binary Log)
2. 備庫將主庫上的日誌複製到本身的中繼日誌(Relay Log)
3. 備庫讀取中繼日誌中的事件,將其重放到備庫數據上
4. 侷限: 主庫上併發運行的查詢在備庫只能串行化執行,由於只有一個sql線程重放中繼日誌事件,這是不少工做負載的性能瓶頸

2.4 複製配置

1. 在每臺服務器上建立複製帳號: 須要REPLICATION SLAVE權限
2. 配置主庫和備庫: 每一個服務器的ID須要惟一不能衝突
3. 通知備庫鏈接到主庫並從主庫複製數據
4. CHANGE MASTER TO: 指定備庫鏈接的主庫設置
5. SHOW SLAVE STATUS: 檢查複製是否正確執行
6. START SLAVE: 開始複製
7. SHOW PROCESSLIST: 查看複製線程,IO線程(發送或獲取日誌),SQL線程(重放日誌)
8. 推薦配置: 開啓sync_binlog

2.5 從另外一個服務器開始複製

問題: 主庫已經運行一段時間,用一臺新安裝的備庫與之同步
保持同步條件:

1. 某個時間點的主庫的數據快照
2. 主庫當前的二進制日誌文件,和得到數據快照時在該二進制日誌文件中的偏移量.經過這兩個能夠肯定二進制日誌的位置
3. 從快照時間到如今的二進制日誌

克隆備庫方法:

1. 冷備份: 關閉主庫,複製數據.主庫重啓後會使用新的二進制文件,在備庫指向這個文件的起始處
2. 熱備份:若是隻有MyISAM,能夠經過mysqlhotcopy或rsync來複制數據
3. 若是隻包含InnoDB: 可使用mysqldump轉儲主庫數據並加載到備庫,而後設置相應的二進制日誌座標
4. 使用快照或備份: 使用主庫的快照或者備份初始化備庫,而後指定二進制日誌座標
5. 使用Percona Xtrabackup: 備份時不阻塞服務器操做,能夠在不影響主庫狀況下設置備庫
6. 使用另外的備庫: 實質就是把另外的備庫當成主庫進行數據克隆

2.6 複製的原理

2.6.1 基於語句的複製

1. 主庫會記錄那些形成數據更改的查詢
2. MySQL5.0以前只支持基於語句的複製
3. 對於函數,存儲過程和觸發器在基於語句的複製模式可能存在問題
4. 更新必須是串行,須要更多的鎖

2.6.2 基於行的複製

1. 將實際的數據記錄在二進制日誌
2. 可以更高效複製數據
3. 基於行的複製事件格式,對人不可讀,可使用mysqlbinlog
4. 很難進行時間點恢復
5. 有些操做,如全表更新(update)複製開銷會很大

2.7 複製拓撲

2.7.1 基本原則

1. 一個MySQL備庫實例只能有一個主庫
2. 每一個備庫必須有一個惟一的服務器id
3. 一個主庫能夠有多個備庫
4. 若是打開log_slave_update一個備庫能夠把其主庫上的數據變化傳播到其餘備庫

2.7.2 一主多備

1. 適用於少許寫和大量讀,能夠把讀分攤到多個備庫上
2. 看成待用的主庫
3. 放到遠程數據中心,用做災難恢復
4. 做爲備份,培訓,開發或測試服務器

2.7.3 雙主複製

1. 個數據庫互爲主庫和備庫
2. 容易形成數據不一樣步
3. 一般並不建議使用這種模式

2.7.4 主動被動的雙主模式

1. 相似雙主複製,把其中一臺配置爲只讀
2. 相似於建立一個熱備份
3. 能夠用做執行讀操做,備份,離線維護及升級

2.7.5 有備庫的雙主模式

1. 雙主模式下,各自有備庫

2.7.6 主庫,分發主庫和備庫

1. 問題: 備庫足夠多時會對主庫形成很大的負載
2. 方案: 將其中部分備庫當成主庫,分發給更多的備庫
3. 經過分發主庫,能夠對二進制日誌事件執行過濾和重寫規則

2.8 複製管理和維護

1. 監控複製: SHOW MASTER STATUS查看主庫狀態, SHOW BINLOG EVENTS查看複製事件
2. 測量備庫延遲: 可使用Percona Toolkit裏的pt-hearbeat
3. 肯定主備是否一致
4. 備庫換主庫: 難點在於獲取新主庫合適的二進制日誌位置
5. 備庫提高爲主庫分爲計劃內提高和計劃外提高

2.8.1 計劃內提高

1. 中止向老的主庫寫入
2. 備庫遇上主庫
3. 備庫設置爲主庫
4. 將備庫和寫操做指向新主庫,而後開啓主庫的寫入

2.8.2 計劃外提高

當主庫崩潰時,須要提高一臺備庫替代

1. 肯定最新的備庫
2. 讓全部備庫執行完從崩潰前主庫得到的中繼日誌,若是未完成則更換主庫,會丟失原先的日誌事件
3. 從新完成主備的配置

2.9 複製的問題和解決方案

2.9.1 數據損壞或丟失

1. 主庫意外關閉: 主庫開啓sync_binlog避免事件丟失,使用Percona Toolkit中的pt-table-checksum檢查主備一致性
2. 備庫意外關閉: 重啓後觀察MySQL錯誤日誌,想方法獲取備庫指向主庫的日誌偏移量
3. 主庫上的二進制日誌損壞: 跳過全部損壞的事件,手動找到一個無缺的事件開始
4. 備庫上的中繼日誌損壞: MySQL5.5後能在崩潰後自動從新獲取中繼日誌
5. 二進制日誌於InnoDB事務日誌不一樣步: 除非備庫中繼日誌有保存,不然自求多福

2.9.2 其餘

1. 若是使用myisam,在關閉Mysql前須要確保已經運行了stop slave,不然在服務器關閉時會kill全部正在運行的查詢.
2. 若是是事務型,失敗的更新會在主庫上回滾並且不會記錄到二進制日誌
3. 避免混用事務和非事務: 若是備庫發生死鎖而主庫沒有,事務型會回滾而非事務型則不會形成不一樣步
4. 主庫和備庫使用不一樣存儲引擎容易致使問題
5. 不惟一和未定義備庫服務器id
6. 避免在主庫上建立備庫上沒有的表,由於複製可能中斷
7. 基於語句複製時,主庫上沒有安全使用臨時表的方法.丟失臨時表: 備庫崩潰時,任何複製線程擁有的臨時表都會丟失,重啓備庫後全部依賴臨時表的語句都會失敗
8. InnoDB加鎖讀引發的鎖爭用: 將大命令拆成小命令能夠有效減小鎖競爭
9. 過大的複製延遲: 定位執行慢的語句,改善機器配置
10. 其餘: 查看官網手冊

2.10 複製高級特性

1. 半同步複製: 當提交事務,客戶端收到查詢結束反饋前必須保證二進制日誌已經傳輸到至少一臺備庫上,主庫將事務提交到磁盤上以後會增長一些延遲
2. 複製心跳: 保證備庫一直與主庫相聯繫,若是出現斷開的網絡鏈接,備庫會注意到丟失的心跳數據

2.11 其餘複製技術

1. Percona XtraDB Cluster的同步複製
2. Tungsten