溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“高性能MySQL復制與緩存的用法”，在日常操作中，相信很多人在高性能MySQL復制與緩存的用法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”高性能MySQL復制與緩存的用法”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
復制解決的基本問題
讓一臺服務器的數據讓其他服務器保持同步，一臺主庫的數據可以同步到多臺備庫上，悲苦本身也可以被配置成另外一臺服務器的主庫。
MySQL支持兩種復制方式：基于行的復制和基于語句的復制（邏輯復制）。這兩種都是在主庫上記錄二進制日志，在備庫重放日志的方式來實現異步的數據復制， 這說明同一時間主備庫存在不一致，并且無法保證主備之間的延遲。
常見的復制用途
數據分布：MySQL通常復制不會造成很大的貸款壓力，但基于行的復制會比基于語句的復制帶寬壓力大， 可以隨意停止或開始復制，并在不同的地理位置來分布數據備份，例如不同的數據中心， 即使在不穩定的網絡環境下，遠程復制也可以工作，單位了低復制延遲，最好有一個穩定的低延遲連接。
負載均衡：將讀操作分布到多個服務器上，實現對讀密集型應用的優化
備份：對備份來說，復制是一項很有意義的技術補充，但復制既不是備份也不能取代備份。
高可用性和故障切換：幫助應用程序避免MySQL單點失敗，一個包含復制的設計良好的故障切換系統能夠顯著地縮短宕機時間
MySQL升級測試：使用一個更高版本的MySQL作為備庫，保證在升級全部實例之前。查詢能夠在備庫按照預期執行。
復制步驟
主庫把數據更改記錄到二進制日志中
在提交失誤完成數據更新前，主庫將數據更新的時間記錄到二進制日志中，按照事務提交的順序 而非每條語句的執行順序來記錄二進制日志，在記錄之后，主庫會告訴存儲引擎可以提交事物了。
備庫將主庫上的日志復制到自己的中繼日志中
備庫讀取中繼日志中的時間，將其重放到備庫數據之上
基于語句的復制
主庫會記錄那些造成數據更改的查詢，當悲苦讀取并重放這些事件時，實際上這只是把主庫上執行過的SQL在執行一遍
優勢：實現簡單，二進制日志里面的時間更加緊湊，不會使用太多帶寬
劣勢：更新必須串行，需要更多的鎖，不是所有的引擎都支持這種復制模式，存在一些無法被正確復制的SQL， 存儲過程和觸發器在使用基于語句的復制模式時也可能存在問題
基于行的復制
將實際數據記錄在二進制日志中，可以正確復制每一行，一些語句可以被更有效的復制
一主多備結構
為不同的角色使用不同的備庫比如 添加不同的所以或使用不同的存儲引擎
把一臺備庫當做代用的主庫，除了復制沒有其他數據傳輸
將一臺備庫放到遠程數據中心，用作災難恢復
延遲一個或多個備庫，以備災難恢復
使用一個備庫作為備份、培訓、開發、或者測試使用服務器
主-被動模式服務器對稱設置
確保兩臺服務器上有相同的數據
啟用二進制日志，選擇唯一的服務器ID，并創建復制賬號
啟用備庫更新的日志記錄
把被動服務器配置成只讀，防止可能與主動服務器上的更新產生沖突
啟動每個服務器的MySQL實例
將每個主庫設置為對方的備庫，使用新建的二進制日志開始工作
主動服務器上更新時：更新記錄到二進制日志中，通過復制傳遞給被動服務器的中繼日志中 被動服務器執行查詢并將其記錄到自己的二進制日志中，由于事件的服務器ID與主動服務器的 相同，因此主動服務器忽略這些事件。
這種類似于創建一個熱備份，但是可以使用這個備份來提高性能，比如執行讀操作、備份、離線 維護升級等。但是不會獲得比單臺服務器更好的寫性能。
擁有備庫的主-主結構
為每一個主庫增加一個備庫，增加了冗余，對于不同地理位置的復制拓撲，能夠消除站點但電視系哦啊的問題 可以將讀查詢分配到備庫上
主庫失效時，用備庫來代替主庫是可行的，也可以把備庫只想一個不同的主庫，但需要考慮增加的復雜度
環形復制拓撲
每一個服務器都是他之前服務器的備庫，是他之后服務器的主庫
主庫 分發主庫 備庫
分發主庫實際上也是一個備庫，他的目的是提取和提供主庫的二進制日志 多個備庫連接到分發主庫，原來的主庫擺脫了負擔，為了避免在分發主庫上做實際的查詢， 可以將他的表修改為blackhole存儲引擎
可以使用分發主庫實現對二進制日志時間執行過濾和重寫規則，這個比在每個備庫上重復進行日志記錄、 重寫和過濾效率高得多
在分發主庫上使用blackhole表，可以支持更多的備庫，雖然會在分發主庫上執行查詢， 但其代價非常小，因為blackhole的表里面沒有任何數據，blackhole表的缺點是存在bug， 在某些情況下會忘記將自增的id寫入二進制日志
使用分發主庫無法使用一個備庫來代替主庫，因為分發主庫的存在，導致各個備庫與原始主庫的二進制日志坐標已經不相同
日志服務器
mysqlbinlog：用來記錄mysql內部增刪改查等對數據庫有更新的內容的記錄，對數據庫的查詢select或show等不會被binlog記錄，主要用于數據庫的主從復制以及增量恢復
復制作為應用二進制日志的方法已經被大量的用戶所測試，能夠證明是可行的的，mysqlbinlog可能無法正確生成二進制日志中的數據更新
復制的速度更快，因為無需將語句從日志導出來并傳送給mysql
很容易觀察到復制過程
方便處理錯誤，例如可以跳過執行失敗的語句
方便過濾復制事件
有時候mysqlbinlog會因為日志記錄格式更改無法讀取二進制日志
緩存
應用層以下的緩存：MySQL服務器有自己的內部緩存，也可以構建自己的緩存和匯總表，緩存表比許多應用層緩存更加持久，在服務器重啟之后他們還存在
應用層緩存：在同一臺機器的內存中緩存數據，或者通過網絡存在另一臺機器的內存中， 應用層緩存可以節省獲取數據以及基于這些數據進行計算。但是緩存命中率低，并且可能使用更多的內存。
應用緩存之本地緩存：小，只在進程處理請求期間存在于進程內存中。可以避免對某些資源的重復請求
應用緩存之本地共享內存緩存：中等大小，快速，難以在多臺機器間同步，對小型的半靜態位數據比較合適 ，但是訪問非常快，通常比任何遠程緩存訪問都快
應用緩存之分布式內存緩存：比本地共享內存緩存大得多，增長容易，緩存中創建的數據的每一個比特都只有一個副本，不會浪費內存，也不會因為緩存創建的數據存在不同的地方而引入一致性問題。 非常適合存儲共享對象，但是演示高，最有效的方法是批量進行多個獲取操作，還要考慮怎么增加更多的節點， 以及某個節點崩潰了怎么處理，應用程序必須決定在節點間怎么分布或充分不緩存對象
應用緩存之磁盤緩存：最好是持久性對象，很難全部存進內存的對象或者金泰內容
緩存控制策略
問題：重復數據，有多而地方需要更新數據，所以要避免督導臟數據
TTL（time to live 存活時間）：緩存對象存儲是設置一個過期時間，可以通過清理進程在未達到過期時間后刪除對象， 或者留到下次訪問時再清理，對于數據很少變更或沒有新數據的情況，這是最好的失效策略。
顯示失效：如果不能接受臟數據，那么在更新原始數據時同時使緩存失效
寫——失效：標記緩存數據已經過期（是否清理緩存數據是可選的）。
寫——更新：更新數據時替換掉緩存項
讀時失效：采用對象版本控制
緩存對象分層：分層緩存對象對檢索、失效和內存利用都有幫助，相對于只緩存對象，也可以緩存對象的ID、對象的ID組等需要一起檢索的數據
預生成內容：在后臺預先請求一些頁面，并將結果存為靜態頁面。
作為基礎組件的緩存
使用handlerSocket 和memcached：handlerSocketto 剛剛一個簡單的協議訪問innodb handler 繞過上層的服務器層，通過網絡直接連接innodb引擎，通過memcached協議訪問innoDB
到此，關于“高性能MySQL復制與緩存的用法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
