2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

0x00前言

本書講述到定稿前的MySQL5.5版，所以下面內(nèi)容的適用范圍止步于MySQL5.5。本文僅僅強(qiáng)調(diào)書中講述的重中之重， 以便快速查閱，詳細(xì)的內(nèi)容還請(qǐng)認(rèn)真閱讀書本和MySQL的官方文檔。

0x01簡介

本章闡述所有與復(fù)制相關(guān)的內(nèi)容

• 簡要介紹復(fù)制如何工作
• 討論基本的復(fù)制服務(wù)搭建
• 與復(fù)制相關(guān)的配置
• 如何管理和優(yōu)化復(fù)制服務(wù)器

0x02復(fù)制概述

• MySQL支持兩種復(fù)制方式：基于行的復(fù)制和基于語句的復(fù)制。
• 都是通過主庫上記錄二進(jìn)制日志，雖然有開銷，但是不會(huì)很大。
• 同一時(shí)間點(diǎn)備庫上的數(shù)據(jù)可能與主庫存在不一致性，并無法保證主備之間的延遲。
• 通過復(fù)制可以將讀操作指向備庫來獲得更好地讀擴(kuò)展。
• 目前備庫只能串行化執(zhí)行。

復(fù)制解決的問題

• 數(shù)據(jù)分布
• 負(fù)載均衡
• 備份
• 高可用性和故障切換
• MySQL升級(jí)

復(fù)制如何工作

• 主庫把數(shù)據(jù)更改記錄到二進(jìn)制日志中。
• 備庫將主庫上的日志復(fù)制到自己的中繼日志中。
• 備庫讀取中繼日志中的事件，將其重放到備庫數(shù)據(jù)之上。

<!-- more -->

0x03配置復(fù)制（略）

0x04復(fù)制的原理

現(xiàn)在一般使用基于行的復(fù)制更佳。

基于語句的復(fù)制（邏輯復(fù)制）

優(yōu)點(diǎn)

• 實(shí)現(xiàn)相當(dāng)簡單
• 不用太多帶寬
• 容易理解

缺點(diǎn)

• 很多情況無法正確復(fù)制，如使用了now()等函數(shù)
• 若使用了觸發(fā)器或者存儲(chǔ)過程也最好不要使用

基于行的復(fù)制

優(yōu)點(diǎn)

• 減少鎖的使用，更高效地復(fù)制數(shù)據(jù)
• 占用更少的CPU
• 解決數(shù)據(jù)不一致的情況

缺點(diǎn)

• 無法知道服務(wù)器正在做什么
• 無法處理諸如在備庫修改表的schema的情況
• 帶寬較高

0x05復(fù)制拓?fù)?#xff08;往后補(bǔ)充圖）

MySQL的復(fù)制有一個(gè)限制：每個(gè)備庫只能有一個(gè)主庫，但是可以用一些其他方法來解決這樣的限制。

一主庫多備庫（多用于備份和讀寫分離）

備庫之間根本沒有交互。有以下用途：

• 為不同的角色使用不同的備庫
• 可把一個(gè)備庫當(dāng)做代用的主庫
• 把備庫放在遠(yuǎn)程數(shù)據(jù)中心，用作災(zāi)難恢復(fù)
• 備份，培訓(xùn)，開發(fā)，測試

主動(dòng)-主動(dòng)模式下的主-主復(fù)制

用于兩個(gè)處于不同地理位置的辦公室，并且都需要一份可寫的數(shù)據(jù)拷貝。弊大于利。

主動(dòng)-被動(dòng)模式下的主-主復(fù)制

切換主動(dòng)被動(dòng)服務(wù)器很方便。

擁有備庫的主-主結(jié)構(gòu)（用于增加冗余）

環(huán)形復(fù)制（要避免成環(huán)）

主庫、分發(fā)主庫以及備庫

• 當(dāng)備庫足夠多時(shí)。會(huì)對(duì)主庫造成很大的負(fù)載，于是需要采用blackhole存儲(chǔ)引擎的分發(fā)主庫。
• 不一定只使用一個(gè)分發(fā)主庫。
• blackhole表沒有任何數(shù)據(jù)，但是目前有bug

樹或金字塔形

定制的復(fù)制方案

• 選擇復(fù)制性
• 分離功能（分離OLTP和OLAP）
• 數(shù)據(jù)歸檔
• 將備庫用作全文索引
• 只讀備庫
• 模擬多主庫復(fù)制
• 創(chuàng)建沒有數(shù)據(jù)的日志服務(wù)器

0x06復(fù)制和容量規(guī)劃

主備庫的模式下，并不是增加備庫就能線性增加讀寫功能。并且在開啟復(fù)制功能時(shí)，要考慮監(jiān)控延時(shí)，可用性。

0x07 MySQL復(fù)制的高級(jí)特性

半同步復(fù)制

可以幫助確保備庫擁有主庫數(shù)據(jù)的拷貝，減少潛在的數(shù)據(jù)丟失危機(jī)。有助于備庫提供更好地冗余度和持久性。 半同步復(fù)制在提交過程中增加一個(gè)延遲：當(dāng)提交事務(wù)時(shí)，在客戶端接收到查詢結(jié)束反饋前必須保證二進(jìn)制日志已經(jīng)傳輸 到至少一臺(tái)備庫上。

• 在主庫上已經(jīng)完成事務(wù)提交，只有通知客戶端被延遲了。
• 備庫在接收到事務(wù)后發(fā)送反饋而非（備庫）完成事務(wù)后發(fā)送。
• 如果備庫一直沒有回應(yīng)已收到事件，會(huì)超時(shí)并轉(zhuǎn)化為正常的異步復(fù)制模式。

復(fù)制心跳

保持備庫一直與主庫相聯(lián)系，避免悄無聲息地?cái)嚅_連接。

0x08小結(jié)

• KISS原則（Keep It Simple Stupid），用簡單的就好。
• 監(jiān)控，監(jiān)控，監(jiān)控，重要的事情說三遍。
• 理解復(fù)制的異步本質(zhì)，且設(shè)計(jì)你的應(yīng)用避免或容忍從備庫讀取臟數(shù)據(jù)。
• 在一個(gè)復(fù)制拓?fù)渲胁灰獙懭攵嘤谝粋€(gè)服務(wù)器，把備庫配置為只讀，并降低權(quán)限以阻止對(duì)數(shù)據(jù)的改變。
• 打開本章鎖討論的明智且安全的設(shè)置。（往后補(bǔ)充）

引用

《高性能MySQL · 第三版》

轉(zhuǎn)載于:https://my.oschina.net/joshuashaw/blog/666674

總結(jié)

以上是生活随笔為你收集整理的《高性能MySQL》の复制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。