mysql主從延遲怎么辦 mysql主從延遲怎么解決

mysql無主鍵無索引表導(dǎo)致同步延遲

Mysql主從同步延遲發(fā)生

魯?shù)榫W(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)公司自2013年起到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。

現(xiàn)象：

pos一直保持不變，并且behind一直在增加，

備庫執(zhí)行：

SQL thread State列狀態(tài)如下：

代表 線程已經(jīng)從中繼日志讀取一個事件，可以對事件進(jìn)行處理了。

查看binlog：

查看表結(jié)構(gòu)發(fā)現(xiàn)沒有主鍵和索引。

延遲發(fā)生原因：

首先mysql主從是基于行的復(fù)制。

舉例解釋下什么是基于行的復(fù)制，假設(shè)主庫執(zhí)行以下sql刪除了表A中的100條數(shù)據(jù)：

這時mysql會把這個SQL按照每條記錄，拆分成100條delete SQL在備庫上執(zhí)行，mysql這么做的目的也是最大程度的保證同步數(shù)據(jù)的可靠性。

但是可靠性的提升伴隨而來的便是日志量的增多，同步過程會占用大量帶寬。

其次，該表即無主鍵，也沒有索引。

假設(shè)還是以上對A表的刪除操作，拆成的100條delete SQL傳遞并且在備庫執(zhí)行，因為表即無主鍵，也沒有索引，所以每執(zhí)行一次都要做全表掃描才能定位到要刪除的那一條數(shù)據(jù)，可想而知同步效率會低很多。

解決方案：

1 表設(shè)計時就要有主鍵；

2 如果延遲已經(jīng)發(fā)生，并且表不是特別大的情況下，在備庫上為該表創(chuàng)建索引或是主鍵。

AWS RDS MySQL 主從同步延遲總結(jié)

最近居然被 MySQL 主從同步的問題坑了, 簡直丟盡了老司機(jī)的臉, 總結(jié)一下.

問題很簡單, 一個業(yè)務(wù)由于 MySQL 主從同步延遲導(dǎo)致讀取的數(shù)據(jù)有問題. 問題解決了, 但如何在 AWS RDS 中獲取 MySQL 的延遲信息呢? 非 AWS RDS 的傳統(tǒng) MySQL 中, 可以直接連到 server 通過 SHOW SLAVE STATUS 獲取延遲信息.

RDS 呢?

AWS 中大多數(shù)(我也不確定是不是所有服務(wù))都接入了 Cloudwatch. Cloudwatch 的好處就是可以作為一個中間層抽象, 將不同系統(tǒng)的數(shù)據(jù)抽象成一個模型, 統(tǒng)一通過 Cloudwatch API 訪問. 就拿主從延遲來說, MySQL/MariaDB 和 PostgeSQL 的計算方法顯然是不一樣的:

因此, 只要通過 Cloudwatch API 獲取 ReplicaLag 這個 metric 的值就可以判斷主從同步延遲, 不管是哪種 DB

看上去挺簡單的 API, 還是需要"進(jìn)城手冊", 避免撓頭:

由于 Cloudwatch 支持的最細(xì)顆粒度的 metric 是1分鐘, 因此僅僅獲取前一分鐘的數(shù)據(jù)可能會有 Cloudwatch 數(shù)據(jù)還未抓取到的問題.

建議是獲取前一段時間(比如10分鐘)的數(shù)據(jù), 確保前10分鐘的 ReplicaLag 都為0(或者小于一個可以接受的值), 則認(rèn)為現(xiàn)在的狀態(tài)是滿足數(shù)據(jù)需求的.

MySQL 主從同步從入行就知道是需要重點關(guān)注的, 結(jié)果還是忽略了一下就掉坑里了. AWS Cloudwatch 也支持根據(jù) ReplicaLag 的值直接告警的, 建議一定要設(shè)置一個.

MySQL 主從，5 分鐘帶你掌握

MySQL 主從一直是面試?？?，里面的知識點雖然基礎(chǔ)，但是能回答全的同學(xué)不多。

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

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

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

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

MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫宕機(jī)時，從庫可以切成主庫，保證服務(wù)的高可用，然后主庫也可以做數(shù)據(jù)的容災(zāi)備份。

整體場景總結(jié)如下：

MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。

主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐?，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步的完成。

詳細(xì)流程如下：

當(dāng)主庫和從庫數(shù)據(jù)同步時，突然中斷怎么辦？因為主庫與從庫之間維持了一個長鏈接，主庫內(nèi)部有一個線程，專門服務(wù)于從庫的這個長鏈接的。

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

我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數(shù)據(jù)一般是不一樣的。

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

那么我們改如何解決呢？

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

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

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

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

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

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

談到 MySQL 數(shù)據(jù)庫主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說起：

總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過從庫一個 SQL 線程所能承受的范圍，那么延時就產(chǎn)生了，當(dāng)然還有就是可能與從庫的大型 query 語句產(chǎn)生了鎖等待。

我們一般會把從庫落后的時間作為一個重點的數(shù)據(jù)庫指標(biāo)做監(jiān)控和報警，正常的時間是在毫秒級別，一旦落后的時間達(dá)到了秒級別就需要告警了。

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

具體解決方案如下：

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

兩臺機(jī)器 A 和 B，A 為主庫，負(fù)責(zé)讀寫，B 為從庫，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，修復(fù)故障后，A 成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。

一臺主庫多臺從庫，A 為主庫，負(fù)責(zé)讀寫，B、C、D為從庫，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。

當(dāng)前題目：mysql主從延遲怎么辦 mysql主從延遲怎么解決
地址分享：http://bm7419.com/article46/dohgpeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、響應(yīng)式網(wǎng)站、域名注冊、外貿(mào)建站、App開發(fā)、App設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)