高性能MySQL複製與緩存

1. 複製解決的基本問題
2. 讓一臺服務器的數據讓其他服務器保持同步，一臺主庫的數據可以同步到多臺備庫上，悲苦本身也可以被配置成另外一臺服務器的主庫。
3. MySQL支持兩種複製方式：基於行的複製和基於語句的複製（邏輯複製）。這兩種都是在主庫上記錄二進制日誌，在備庫重放日誌的方式來實現異步的數據複製， 這說明同一時間主備庫存在不一致，並且無法保證主備之間的延遲。
4. 常見的複製用途
5. 數據分佈：MySQL通常複製不會造成很大的貸款壓力，但基於行的複製會比基於語句的複製帶寬壓力大， 可以隨意停止或開始複製，並在不同的地理位置來分佈數據備份，例如不同的數據中心， 即使在不穩定的網絡環境下，遠程複製也可以工作，單位了低複製延遲，最好有一個穩定的低延遲連接。
6. 負載均衡：將讀操作分佈到多個服務器上，實現對讀密集型應用的優化
7. 備份：對備份來說，複製是一項很有意義的技術補充，但複製既不是備份也不能取代備份。
8. 高可用性和故障切換：幫助應用程序避免MySQL單點失敗，一個包含複製的設計良好的故障切換系統能夠顯著地縮短宕機時間
9. MySQL升級測試：使用一個更高版本的MySQL作為備庫，保證在升級全部實例之前。查詢能夠在備庫按照預期執行。
10. 複製步驟
11. 主庫把數據更改記錄到二進制日誌中
12. 在提交失誤完成數據更新前，主庫將數據更新的時間記錄到二進制日誌中，按照事務提交的順序 而非每條語句的執行順序來記錄二進制日誌，在記錄之後，主庫會告訴存儲引擎可以提交事物了。
13. 備庫將主庫上的日誌複製到自己的中繼日誌中
14. 備庫讀取中繼日誌中的時間，將其重放到備庫數據之上
15. 基於語句的複製
16. 主庫會記錄那些造成數據更改的查詢，當悲苦讀取並重放這些事件時，實際上這只是把主庫上執行過的SQL在執行一遍
17. 優勢：實現簡單，二進制日誌裡面的時間更加緊湊，不會使用太多帶寬
18. 劣勢：更新必須串行，需要更多的鎖，不是所有的引擎都支持這種複製模式，存在一些無法被正確複製的SQL， 存儲過程和觸發器在使用基於語句的複製模式時也可能存在問題
19. 基於行的複製
20. 將實際數據記錄在二進制日誌中，可以正確複製每一行，一些語句可以被更有效的複製
21. 一主多備結構
22. 為不同的角色使用不同的備庫比如 添加不同的所以或使用不同的存儲引擎
23. 把一臺備庫當做代用的主庫，除了複製沒有其他數據傳輸
24. 將一臺備庫放到遠程數據中心，用作災難恢復
25. 延遲一個或多個備庫，以備災難恢復
26. 使用一個備庫作為備份、培訓、開發、或者測試使用服務器
27. 主-被動模式服務器對稱設置
28. 確保兩臺服務器上有相同的數據
29. 啟用二進制日誌，選擇唯一的服務器ID，並創建複製賬號
30. 啟用備庫更新的日誌記錄
31. 把被動服務器配置成只讀，防止可能與主動服務器上的更新產生衝突
32. 啟動每個服務器的MySQL實例
33. 將每個主庫設置為對方的備庫，使用新建的二進制日誌開始工作
34. 主動服務器上更新時：更新記錄到二進制日誌中，通過複製傳遞給被動服務器的中繼日誌中 被動服務器執行查詢並將其記錄到自己的二進制日誌中，由於事件的服務器ID與主動服務器的 相同，因此主動服務器忽略這些事件。
35. 這種類似於創建一個熱備份，但是可以使用這個備份來提高性能，比如執行讀操作、備份、離線 維護升級等。但是不會獲得比單臺服務器更好的寫性能。
36. 擁有備庫的主-主結構
37. 為每一個主庫增加一個備庫，增加了冗餘，對於不同地理位置的複製拓撲，能夠消除站點但電視系哦啊的問題 可以將讀查詢分配到備庫上
38. 主庫失效時，用備庫來代替主庫是可行的，也可以把備庫只想一個不同的主庫，但需要考慮增加的複雜度
39. 環形複製拓撲
40. 每一個服務器都是他之前服務器的備庫，是他之後服務器的主庫
41. 主庫 分發主庫 備庫
42. 分發主庫實際上也是一個備庫，他的目的是提取和提供主庫的二進制日誌 多個備庫連接到分發主庫，原來的主庫擺脫了負擔，為了避免在分發主庫上做實際的查詢， 可以將他的表修改為blackhole存儲引擎
43. 可以使用分發主庫實現對二進制日誌時間執行過濾和重寫規則，這個比在每個備庫上重複進行日誌記錄、 重寫和過濾效率高得多
44. 在分發主庫上使用blackhole表，可以支持更多的備庫，雖然會在分發主庫上執行查詢， 但其代價非常小，因為blackhole的表裡面沒有任何數據，blackhole表的缺點是存在bug， 在某些情況下會忘記將自增的id寫入二進制日誌
45. 使用分發主庫無法使用一個備庫來代替主庫，因為分發主庫的存在，導致各個備庫與原始主庫的二進制日誌座標已經不相同
46. 日誌服務器
47. mysqlbinlog：用來記錄mysql內部增刪改查等對數據庫有更新的內容的記錄，對數據庫的查詢select或show等不會被binlog記錄，主要用於數據庫的主從複製以及增量恢復
48. 複製作為應用二進制日誌的方法已經被大量的用戶所測試，能夠證明是可行的的，mysqlbinlog可能無法正確生成二進制日誌中的數據更新
49. 複製的速度更快，因為無需將語句從日誌導出來並傳送給mysql
50. 很容易觀察到複製過程
51. 方便處理錯誤，例如可以跳過執行失敗的語句
52. 方便過濾複製事件
53. 有時候mysqlbinlog會因為日誌記錄格式更改無法讀取二進制日誌
54. 緩存
55. 應用層以下的緩存：MySQL服務器有自己的內部緩存，也可以構建自己的緩存和彙總表，緩存表比許多應用層緩存更加持久，在服務器重啟之後他們還存在
56. 應用層緩存：在同一臺機器的內存中緩存數據，或者通過網絡存在另一臺機器的內存中， 應用層緩存可以節省獲取數據以及基於這些數據進行計算。但是緩存命中率低，並且可能使用更多的內存。
57. 應用緩存之本地緩存：小，只在進程處理請求期間存在於進程內存中。可以避免對某些資源的重複請求
58. 應用緩存之本地共享內存緩存：中等大小，快速，難以在多臺機器間同步，對小型的半靜態位數據比較合適 ，但是訪問非常快，通常比任何遠程緩存訪問都快
59. 應用緩存之分佈式內存緩存：比本地共享內存緩存大得多，增長容易，緩存中創建的數據的每一個比特都只有一個副本，不會浪費內存，也不會因為緩存創建的數據存在不同的地方而引入一致性問題。 非常適合存儲共享對象，但是演示高，最有效的方法是批量進行多個獲取操作，還要考慮怎麼增加更多的節點， 以及某個節點崩潰了怎麼處理，應用程序必須決定在節點間怎麼分佈或充分不緩存對象
60. 應用緩存之磁盤緩存：最好是持久性對象，很難全部存進內存的對象或者金泰內容
61. 緩存控制策略
62. 問題：重複數據，有多而地方需要更新數據，所以要避免督導髒數據
63. TTL（time to live 存活時間）：緩存對象存儲是設置一個過期時間，可以通過清理進程在未達到過期時間後刪除對象， 或者留到下次訪問時再清理，對於數據很少變更或沒有新數據的情況，這是最好的失效策略。
64. 顯示失效：如果不能接受髒數據，那麼在更新原始數據時同時使緩存失效
65. 寫——失效：標記緩存數據已經過期（是否清理緩存數據是可選的）。
66. 寫——更新：更新數據時替換掉緩存項
67. 讀時失效：採用對象版本控制
68. 緩存對象分層：分層緩存對象對檢索、失效和內存利用都有幫助，相對於只緩存對象，也可以緩存對象的ID、對象的ID組等需要一起檢索的數據
69. 預生成內容：在後臺預先請求一些頁面，並將結果存為靜態頁面。
70. 作為基礎組件的緩存
71. 使用handlerSocket 和memcached：handlerSocketto 剛剛一個簡單的協議訪問innodb handler 繞過上層的服務器層，通過網絡直接連接innodb引擎，通過memcached協議訪問innoDB

閱讀更多 程序員小新人學習 的文章

關鍵字: 一臺 Memcached 服務器