服務(wù)在運(yùn)行過程中存在很多意外情況，如：如服務(wù)器宕機(jī)帜羊、磁盤損壞咒程、RAID卡損壞等。如何保證數(shù)據(jù)庫在服務(wù)發(fā)生意外的情況下數(shù)據(jù)不丟失呢讼育？服務(wù)還能繼續(xù)提供服務(wù)呢帐姻？
我們一般通過備份的方式來解決數(shù)據(jù)丟失問題，通過復(fù)制來解決MySQL的高可用問題窥淆。
備份
備份的方法不同可以將備份分為：
- Hot Backup（熱備卖宠，在線備份）：在數(shù)據(jù)運(yùn)行過程中進(jìn)行備份，對數(shù)據(jù)庫操作沒有影響忧饭。
- Cold Backup（冷備扛伍，離線備份）：在數(shù)據(jù)停止情況下，直接拷貝數(shù)據(jù)庫物理文件词裤。
- Warm Backup（溫備）：在數(shù)據(jù)運(yùn)行過程中進(jìn)行刺洒，但是會對當(dāng)前數(shù)據(jù)庫的操作有所影響，如加一個全局讀鎖以保證備份數(shù)據(jù)的一致性吼砂。
按照備份后文件的內(nèi)容逆航，備份又可以分為：
- 邏輯備份：是指備份出的文件內(nèi)容是可讀的，一般是文本文件渔肩。內(nèi)容一般是由一條條SQL語句因俐，或者是表內(nèi)實(shí)際數(shù)據(jù)組成。一般適用于數(shù)據(jù)庫的升級周偎、遷移等工作抹剩。但其缺點(diǎn)是恢復(fù)所需要的時間往往較長。
- 裸文件備份：是指復(fù)制數(shù)據(jù)庫的物理文件蓉坎，既可以是在數(shù)據(jù)庫運(yùn)行中的復(fù)制（如ibbackup澳眷、xtrabackup這類工具），也可以是在數(shù)據(jù)庫停止運(yùn)行時直接的數(shù)據(jù)文件復(fù)制蛉艾。這類備份的恢復(fù)時間往往較邏輯備份短很多钳踊。
若按照備份數(shù)據(jù)庫的內(nèi)容來分衷敌，備份又可以分為：
- 完全備份：完全備份是指對數(shù)據(jù)庫進(jìn)行一個完整的備份。
- 增量備份：增量備份是指在上次完全備份的基礎(chǔ)上拓瞪，對于更改的數(shù)據(jù)進(jìn)行備份缴罗。
- 日志備份：日志備份主要是指對MySQL數(shù)據(jù)庫二進(jìn)制日志的備份，通過對一個完全備份進(jìn)行二進(jìn)制日志的重做（replay）來完成數(shù)據(jù)庫的point-in-time的恢復(fù)工作祭埂。
復(fù)制
復(fù)制（replication）是MySQL數(shù)據(jù)庫提供的一種高可用高性能的解決方案瞒爬，一般用來建立大型的應(yīng)用，原理如下：
- 主服務(wù)器（master）把數(shù)據(jù)更改記錄到二進(jìn)制日志（binlog）中沟堡，然后通過
binary log dump線程將二進(jìn)制文件推送到從服務(wù)器。 - 從服務(wù)器（slave）通過I/O線程矢空，把主服務(wù)器的二進(jìn)制日志復(fù)制到自己的中繼日志（relay log）中航罗，中繼日志通常會位于os緩存中，所以中繼日志的開銷很小屁药。
- 從服務(wù)器通過SQL線程重做中繼日志中的日志粥血，把更改應(yīng)用到自己的數(shù)據(jù)庫上，以達(dá)到數(shù)據(jù)的最終一致性酿箭。
從服務(wù)器有2個線程复亏，一個是I/O線程，負(fù)責(zé)讀取主服務(wù)器的二進(jìn)制日志缭嫡，并將其保存為中繼日志缔御；另一個是SQL線程，復(fù)制執(zhí)行中繼日志妇蛀。這里需要特別注意的是耕突，復(fù)制是一個異步過程，從服務(wù)器數(shù)據(jù)存在延遲评架。
MySQL二進(jìn)制日志文件Binlog有三種格式眷茁，Statement、Row和Mixed纵诞，所以MySQL的復(fù)制也對應(yīng)有三種方式上祈。
異步復(fù)制
主庫執(zhí)行完Commit后，在主庫寫入Binlog日志后即可成功返回客戶端浙芙，無需等Binlog日志傳送給從庫登刺。
半同步復(fù)制
在 MySQL5.5之前，MySQL的復(fù)制是異步操作茁裙，主庫和從庫的數(shù)據(jù)之間存在一定的延遲塘砸，這樣存在一個隱患：當(dāng)在主庫上寫人一個事務(wù)并提交成功，而從庫尚未得到主庫推送的Binlog日志時晤锥，主庫宕機(jī)了掉蔬，例如主庫可能因磁盤損壞廊宪、內(nèi)存故障等造成主庫上該事務(wù) Binlog丟失，此時從庫就可能損失這個事務(wù)女轿，從而造成主從不一致箭启。
而半同步復(fù)制，是等待其中一個從庫也接收到Binlog事務(wù)并成功寫入Relay Log之后蛉迹，才返回Commit操作成功給客戶端傅寡；如此半同步就保證了事務(wù)成功提交后至少有兩份日志記錄，一份在主庫Binlog上北救，另一份在從庫的Relay Log上荐操，從而進(jìn)一步保證數(shù)據(jù)完整性；半同步復(fù)制很大程度取決于主從網(wǎng)絡(luò)RTT（往返時延）珍策，以插件 semisync_master/semisync_slave 形式存在托启。
集群
使用集群可以提高M(jìn)ySQL服務(wù)器的可用性和性能，MySQL服務(wù)支持多種集群方案攘宙。
MySQL Cluster
由Mysql本身提供屯耸，優(yōu)勢：可用性非常高，性能非常好蹭劈。每份數(shù)據(jù)至少可在不同主機(jī)存一份拷貝疗绣，且冗余數(shù)據(jù)拷貝實(shí)時同步。但它的維護(hù)非常復(fù)雜铺韧，存在部分Bug多矮，目前還不適合比較核心的線上系統(tǒng)，所以不推薦哈打。
DRBD磁盤網(wǎng)絡(luò)鏡像
Distributed Replicated Block Device工窍，其實(shí)現(xiàn)方式是通過網(wǎng)絡(luò)來鏡像整個設(shè)備(磁盤)。它允許用戶在遠(yuǎn)程機(jī)器上建立一個本地塊設(shè)備的實(shí)時鏡像前酿，與心跳鏈接結(jié)合使用患雏，也可看做一種網(wǎng)絡(luò)RAID。
優(yōu)勢：軟件功能強(qiáng)大罢维，數(shù)據(jù)可在底層快設(shè)備級別跨物理主機(jī)鏡像淹仑，且可根據(jù)性能和可靠性要求配置不同級別的同步。IO操作保持順序肺孵，可滿足數(shù)據(jù)庫對數(shù)據(jù)一致性的苛刻要求匀借。
但非分布式文件系統(tǒng)環(huán)境無法支持鏡像數(shù)據(jù)同時可見，性能和可靠性兩者相互矛盾平窘，無法適用于性能和可靠性要求都比較苛刻的環(huán)境吓肋，維護(hù)成本高于MySQL Replication。另外瑰艘，DRBD也是官方推薦的可用于MySQL高可用方案之一是鬼，所以這個大家可根據(jù)實(shí)際環(huán)境來考慮是否部署肤舞。
MySQL Replication
MySQL的復(fù)制上在實(shí)際應(yīng)用場景中使用最多的一種方案，主要優(yōu)勢是成本低均蜜，實(shí)現(xiàn)起來比較簡單李剖，缺點(diǎn)是從服務(wù)器存在一定的延遲。
常用架構(gòu)
一主多從囤耳，提高系統(tǒng)的讀性能
一主一從和一主多從是最常見的主從架構(gòu)篙顺，實(shí)施起來簡單并且有效，主要用來實(shí)現(xiàn)讀寫分離充择，提升度的性能德玫，降低主庫壓力，在主庫出現(xiàn)異常宕機(jī)的情況下椎麦，可以把一個從庫切換為主庫繼續(xù)提供服務(wù)化焕。
多級復(fù)制
MySQL的復(fù)制是主庫推送Binlog到從庫，在上面一主多從的情況下铃剔，主庫的I/O和網(wǎng)絡(luò)壓力都會隨著從庫的增加而增大。多級而使用多級復(fù)制可以很好的解決這個問題查刻，但是隨著從庫的鏈路的增加從庫的數(shù)據(jù)延遲也會隨著增大键兜。
雙主復(fù)制/Dual Master
其實(shí)就是master1和master2互為主從關(guān)系，這樣任何一方所做的變更穗泵，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中普气。client客戶端的寫請求都訪問主庫 Master1，而讀請求可以選擇訪問主庫Master1或 Master2佃延。
雙主多級復(fù)制架構(gòu)
雙主復(fù)制還能和主從復(fù)制聯(lián)合起來使用现诀，在 Master2庫下配置從庫 Slave1、 Slave2等履肃，這樣即可通過從庫Slave等來分擔(dān)讀取壓力仔沿。
