mysql數據庫主從備份的好處,mysql數據庫備份策略

本文目錄一覽：

• 1、mysql主從複製是什麼概念？什麼場合用？最好舉例說明。
• 2、為什麼要對MySQL做主從同步複製
• 3、mysql主主複製 優缺點
• 4、為什麼使用mysql主從數據庫，而不考慮使用緩存
• 5、MySQL 主從，5 分鐘帶你掌握

mysql主從複製是什麼概念？什麼場合用？最好舉例說明。

主從複製，是用來建立一個和主數據庫完全一樣的數據庫環境，稱為從數據庫；主數據庫一般是實時的業務數據庫

MySQL是一個關係型數據庫管理系統，由瑞典MySQL AB 公司開發，目前屬於 Oracle 旗下產品。MySQL 最流行的關係型數據庫管理系統，在 WEB 應用方面MySQL是最好的 RDBMS (Relational Database Management System，關係數據庫管理系統) 應用軟件之一。

MySQL是一種關聯數據庫管理系統，關聯數據庫將數據保存在不同的表中，而不是將所有數據放在一個大倉庫內，這樣就增加了速度並提高了靈活性。

與其他的大型數據庫例如Oracle、DB2、SQL Server等相比，MySQL 自有它的不足之處，但是這絲毫也沒有減少它受歡迎的程度。

對於一般的個人使用者和中小型企業來說，MySQL提供的功能已經綽綽有餘，而且由於 MySQ L是開放源碼軟件，因此可以大大降低總體擁有成本。

為什麼要對MySQL做主從同步複製

配置主從可以分擔數據庫的壓力,進行讀寫分離,所有的數據庫插入,修改等寫入操作,從主庫進行

所有的數據查詢等讀取操作走從庫,這樣就分擔了單一數據庫示例的運行壓力

mysql主主複製 優缺點

mysql複製主要有三種方式：

1. 基於SQL語句的複製(statement-based replication, SBR)，

(1) 優點：

歷史悠久，技術成熟。

產生的binlog文件較小，比較節省空間。

binlog中包含了所有數據庫更改信息，可以據此來審核數據庫的安全等情況。

binlog可以用於實時的還原，而不僅僅用於複製。

主從版本可以不一樣，從服務器版本可以比主服務器版本高。

(2) 缺點：

不是所有的UPDATE語句都能被複制，尤其是包含不確定操作的時候。

調用具有不確定因素的 UDF 時複製也可能出問題

使用以下函數的語句也無法被複制：

* LOAD_FILE()

* UUID()

* USER()

* FOUND_ROWS()

* SYSDATE() (除非啟動時啟用了 –sysdate-is-now 選項)

INSERT … SELECT 會產生比 RBR 更多的行級鎖

2.基於行的複製(row-based replication, RBR)，

(1)優點：

任何情況都可以被複制，這對複製來說是最安全可靠的

多數情況下，從服務器上的表如果有主鍵的話，複製就會快了很多

複製以下幾種語句時的行鎖更少：

* INSERT … SELECT

* 包含 AUTO_INCREMENT 字段的 INSERT

* 沒有附帶條件或者並沒有修改很多記錄的 UPDATE 或 DELETE 語句

執行 INSERT，UPDATE，DELETE 語句時鎖更少

從服務器上採用多線程來執行複製成為可能。

(2)缺點：

binlog 文件太大

複雜的回滾時 binlog 中會包含大量的數據

主服務器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導致頻繁發生 binlog 的並發寫問題

UDF 產生的大 BLOB 值會導致複製變慢

無法從 binlog 中看到都複製了寫什麼語句，無法進行審計。

3. 混合模式複製(mixed-based replication, MBR)。

是上面兩種方式的折中，對於能用

對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

為什麼使用mysql主從數據庫，而不考慮使用緩存

目的不完全相同

1、數據庫信息量大了一般都要使用主從數據庫，主寫從讀。使用主從數據庫主要是使數據庫能支撐更大的並發，例如：“前台”使用master（主庫），“報表”使用slave（從庫），那麼任何“報表”的sql在slave執行都不會造成“前台”鎖表；另外還有方便熱備份，支持兩個庫用不同引擎等好處

2、而程序里使用緩存多是為了減少對數據庫訪問壓力。

MySQL 主從，5 分鐘帶你掌握

MySQL 主從一直是面試常客，裡面的知識點雖然基礎，但是能回答全的同學不多。

比如樓哥之前面試小米，就被問到過主從複製的原理，以及主從延遲的解決方案，因為回答的非常不錯，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？

所謂 MySQL 主從，就是建立兩個完全一樣的數據庫，一個是主庫，一個是從庫， 主庫對外提供讀寫的操作，從庫對外提供讀的操作 ，下面是一主一從模式：

對於數據庫單機部署，在 4 核 8G 的機器上運行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當遇到一些活動時，查詢流量驟然，就需要進行主從分離。

大部分系統的訪問模型是讀多寫少，讀寫請求量的差距可能達到幾個數量級，所以我們可以通過一主多從的方式， 主庫只負責寫入和部分核心邏輯的查詢，多個從庫只負責查詢，提升查詢性能，降低主庫壓力。

MySQL 主從還能做到服務高可用，當主庫宕機時，從庫可以切成主庫，保證服務的高可用，然後主庫也可以做數據的容災備份。

整體場景總結如下：

MySQL 的主從複製是依賴於 binlog 的，也就是記錄 MySQL 上的所有變化並以二進制形式保存在磁盤上二進制日誌文件。

主從複製就是將 binlog 中的數據從主庫傳輸到從庫上，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步的完成。

詳細流程如下：

當主庫和從庫數據同步時，突然中斷怎麼辦？因為主庫與從庫之間維持了一個長鏈接，主庫內部有一個線程，專門服務於從庫的這個長鏈接的。

對於下面的情況，假如主庫執行如下 SQL，其中 a 和 create_time 都是索引：

我們知道，數據選擇了 a 索引和選擇 create_time 索引，最後 limit 1 出來的數據一般是不一樣的。

所以就會存在這種情況：在 binlog = statement 格式時，主庫在執行這條 SQL 時，使用的是索引 a，而從庫在執行這條 SQL 時，使用了索引 create_time，最後主從數據不一致了。

那麼我們改如何解決呢？

可以把 binlog 格式修改為 row，row 格式的 binlog 日誌記錄的不是 SQL 原文，而是兩個 event:Table_map 和 Delete_rows。

Table_map event 說明要操作的表，Delete_rows event用於定義要刪除的行為，記錄刪除的具體行數。 row 格式的 binlog 記錄的就是要刪除的主鍵 ID 信息，因此不會出現主從不一致的問題。

但是如果 SQL 刪除 10 萬行數據，使用 row 格式就會很占空間的，10 萬條數據都在 binlog 裡面，寫 binlog 的時候也很耗 IO。但是 statement 格式的 binlog 可能會導致數據不一致。

設計 MySQL 的大叔想了一個折中的方案，mixed 格式的 binlog，其實就是 row 和 statement 格式混合使用， 當 MySQL 判斷可能數據不一致時，就用 row 格式，否則使用就用 statement 格式。

有時候我們遇到從數據庫中獲取不到信息的詭異問題時，會糾結於代碼中是否有一些邏輯會把之前寫入的內容刪除，但是你又會發現，過了一段時間再去查詢時又可以讀到數據了，這基本上就是主從延遲在作怪。

主從延遲，其實就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值， 會導致從庫查詢的數據，和主庫的不一致 。

談到 MySQL 數據庫主從同步延遲原理，得從 MySQL 的主從複製原理說起：

總結一下主從延遲的主要原因 ：主從延遲主要是出現在 “relay log 回放” 這一步，當主庫的 TPS 並發較高，產生的 DDL 數量超過從庫一個 SQL 線程所能承受的範圍，那麼延時就產生了，當然還有就是可能與從庫的大型 query 語句產生了鎖等待。

我們一般會把從庫落後的時間作為一個重點的數據庫指標做監控和報警，正常的時間是在毫秒級別，一旦落後的時間達到了秒級別就需要告警了。

解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫。

具體解決方案如下：

在實際應用場景中，對於一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。

兩台機器 A 和 B，A 為主庫，負責讀寫，B 為從庫，負責讀數據。

如果 A 庫發生故障，B 庫成為主庫負責讀寫，修復故障後，A 成為從庫，主庫 B 同步數據到從庫 A。

一台主庫多台從庫，A 為主庫，負責讀寫，B、C、D為從庫，負責讀數據。

如果 A 庫發生故障，B 庫成為主庫負責讀寫，C、D負責讀，修復故障後，A 也成為從庫，主庫 B 同步數據到從庫 A。