本篇內(nèi)容主要講解“MySQL主從延遲問(wèn)題怎么解決”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“MySQL主從延遲問(wèn)題怎么解決”吧!

為特克斯等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及特克斯網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、特克斯網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

什么是主從延遲

在討論如何解決主從延遲之前，我們先了解下什么是主從延遲。

為了完成主從復(fù)制，從庫(kù)需要通過(guò) I/O 線程獲取主庫(kù)中 dump 線程讀取的 binlog 內(nèi)容并寫(xiě)入到自己的中繼日志 relay log 中，從庫(kù)的 SQL 線程再讀取中繼日志，重做中繼日志中的日志，相當(dāng)于再執(zhí)行一遍 SQL，更新自己的數(shù)據(jù)庫(kù)，以達(dá)到數(shù)據(jù)的一致性。

與數(shù)據(jù)同步有關(guān)的時(shí)間點(diǎn)主要包括以下三個(gè)：

1. 主庫(kù)執(zhí)行完一個(gè)事務(wù)，寫(xiě)入 binlog，將這個(gè)時(shí)刻記為 T1；

2. 之后傳給從庫(kù)，將從庫(kù)接收完這個(gè) binlog 的時(shí)刻記為 T2；

3. 從庫(kù)執(zhí)行完成這個(gè)事務(wù)，將這個(gè)時(shí)刻記為 T3。

所謂主從延遲，就是同一個(gè)事務(wù)，從庫(kù)執(zhí)行完成的時(shí)間與主庫(kù)執(zhí)行完成的時(shí)間之差，也就是 T3 - T1。

可以在備庫(kù)上執(zhí)行 show slave status 命令，它的返回結(jié)果里面會(huì)顯示 seconds_behind_master，用于表示當(dāng)前備庫(kù)延遲了多少秒。
seconds_behind_master 的計(jì)算方法是這樣的：

1. 每個(gè)事務(wù)的 binlog 里面都有一個(gè)時(shí)間字段，用于記錄主庫(kù)上寫(xiě)入的時(shí)間；

2. 備庫(kù)取出當(dāng)前正在執(zhí)行的事務(wù)的時(shí)間字段的值，計(jì)算它與當(dāng)前系統(tǒng)時(shí)間的差值，得到 seconds_behind_master。

在網(wǎng)絡(luò)正常的時(shí)候，日志從主庫(kù)傳給從庫(kù)所需的時(shí)間是很短的，即 T2 - T1 的值是非常小的。也就是說(shuō)，網(wǎng)絡(luò)正常情況下，主從延遲的主要來(lái)源是從庫(kù)接收完 binlog 和執(zhí)行完這個(gè)事務(wù)之間的時(shí)間差。

由于主從延遲的存在，我們可能會(huì)發(fā)現(xiàn)，數(shù)據(jù)剛寫(xiě)入主庫(kù)，結(jié)果卻查不到，因?yàn)榭赡苓€未同步到從庫(kù)。主從延遲越嚴(yán)重，該問(wèn)題也愈加明顯。

主從延遲的來(lái)源

主庫(kù)和從庫(kù)在執(zhí)行同一個(gè)事務(wù)的時(shí)候出現(xiàn)時(shí)間差的問(wèn)題，主要原因包括但不限于以下幾種情況：

• 有些部署條件下，從庫(kù)所在機(jī)器的性能要比主庫(kù)性能差。

• 從庫(kù)的壓力較大，即從庫(kù)承受了大量的請(qǐng)求。

• 執(zhí)行大事務(wù)。因?yàn)橹鲙?kù)上必須等事務(wù)執(zhí)行完成才會(huì)寫(xiě)入 binlog，再傳給備庫(kù)。如果一個(gè)主庫(kù)上語(yǔ)句執(zhí)行 10 分鐘，那么這個(gè)事務(wù)可能會(huì)導(dǎo)致從庫(kù)延遲 10 分鐘。

• 從庫(kù)的并行復(fù)制能力。

主從延遲的解決方案

解決主從延遲主要有以下方案：

1. 配合 semi-sync 半同步復(fù)制；

2. 一主多從，分?jǐn)倧膸?kù)壓力；

3. 強(qiáng)制走主庫(kù)方案（強(qiáng)一致性）；

4. sleep 方案：主庫(kù)更新后，讀從庫(kù)之前先 sleep 一下；

5. 判斷主備無(wú)延遲方案（例如判斷 seconds_behind_master 參數(shù)是否已經(jīng)等于 0、對(duì)比位點(diǎn)）；

6. 并行復(fù)制— 解決從庫(kù)復(fù)制延遲的問(wèn)題；

這里主要介紹我在項(xiàng)目中使用的幾種方案，分別是半同步復(fù)制、實(shí)時(shí)性操作強(qiáng)制走主庫(kù)、并行復(fù)制。

semi-sync 半同步復(fù)制

MySQL 有三種同步模式，分別是：

「異步復(fù)制」：MySQL 默認(rèn)的復(fù)制即是異步的，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后會(huì)立即將結(jié)果返給客戶端，并不關(guān)心從庫(kù)是否已經(jīng)接收并處理。這樣就會(huì)有一個(gè)問(wèn)題，一旦主庫(kù)宕機(jī)，此時(shí)主庫(kù)上已經(jīng)提交的事務(wù)可能因?yàn)榫W(wǎng)絡(luò)原因并沒(méi)有傳到從庫(kù)上，如果此時(shí)執(zhí)行故障轉(zhuǎn)移，強(qiáng)行將從提升為主，可能導(dǎo)致新主上的數(shù)據(jù)不完整。

「全同步復(fù)制」：指當(dāng)主庫(kù)執(zhí)行完一個(gè)事務(wù)，并且所有的從庫(kù)都執(zhí)行了該事務(wù)，主庫(kù)才提交事務(wù)并返回結(jié)果給客戶端。因?yàn)樾枰却袕膸?kù)執(zhí)行完該事務(wù)才能返回，所以全同步復(fù)制的性能必然會(huì)收到嚴(yán)重的影響。

「半同步復(fù)制」：是介于全同步復(fù)制與全異步復(fù)制之間的一種，主庫(kù)只需要等待至少一個(gè)從庫(kù)接收到并寫(xiě)到 Relay Log 文件即可，主庫(kù)不需要等待所有從庫(kù)給主庫(kù)返回 ACK。主庫(kù)收到這個(gè) ACK 以后，才能給客戶端返回 “事務(wù)完成” 的確認(rèn)。

MySQL 默認(rèn)的復(fù)制是異步的，所以主庫(kù)和從庫(kù)的數(shù)據(jù)會(huì)有一定的延遲，更重要的是異步復(fù)制可能會(huì)引起數(shù)據(jù)的丟失。但是全同步復(fù)制又會(huì)使得完成一個(gè)事務(wù)的時(shí)間被拉長(zhǎng)，帶來(lái)性能的降低。因此我把目光轉(zhuǎn)向半同步復(fù)制。從 MySQL 5.5 開(kāi)始，MySQL 以插件的形式支持 semi-sync 半同步復(fù)制。

相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，減少了主從延遲，當(dāng)然它也還是有一定程度的延遲，這個(gè)延遲最少是一個(gè) TCP/IP 往返的時(shí)間。所以，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。

需要注意的是：

• 主庫(kù)和從庫(kù)都要啟用半同步復(fù)制才會(huì)進(jìn)行半同步復(fù)制功能，否則主庫(kù)會(huì)還原為默認(rèn)的異步復(fù)制。

• 如果在等待過(guò)程中，等待時(shí)間已經(jīng)超過(guò)了配置的超時(shí)時(shí)間，沒(méi)有收到任何一個(gè)從庫(kù)的 ACK，那么此時(shí)主庫(kù)會(huì)自動(dòng)轉(zhuǎn)換為異步復(fù)制。當(dāng)至少一個(gè)半同步從節(jié)點(diǎn)趕上來(lái)時(shí)，主庫(kù)便會(huì)自動(dòng)轉(zhuǎn)換為半同步復(fù)制。

半同步復(fù)制的潛在問(wèn)題

在傳統(tǒng)的半同步復(fù)制中（MySQL 5.5 引入），主庫(kù)寫(xiě)數(shù)據(jù)到 binlog，并且執(zhí)行 commit 提交事務(wù)后，會(huì)一直等待一個(gè)從庫(kù)的 ACK，即從庫(kù)寫(xiě)入 Relay Log 后，并將數(shù)據(jù)落盤(pán)，再返回給主庫(kù) ACK，主庫(kù)收到這個(gè) ACK 以后，才能給客戶端返回 “事務(wù)完成” 的確認(rèn)。

這樣會(huì)出現(xiàn)一個(gè)問(wèn)題，就是實(shí)際上主庫(kù)已經(jīng)將該事務(wù) commit 到了存儲(chǔ)引擎層，應(yīng)用已經(jīng)可以看到數(shù)據(jù)發(fā)生了變化，只是在等待返回而已。如果此時(shí)主庫(kù)宕機(jī)，可能從庫(kù)還沒(méi)寫(xiě)入 Relay Log，就會(huì)發(fā)生主從庫(kù)數(shù)據(jù)不一致。

為了解決上述問(wèn)題，MySQL 5.7 引入了增強(qiáng)半同步復(fù)制。針對(duì)上面這個(gè)圖，“Waiting Slave dump” 被調(diào)整到了 “Storage Commit” 之前，即主庫(kù)寫(xiě)數(shù)據(jù)到 binlog 后，就開(kāi)始等待從庫(kù)的應(yīng)答 ACK，直到至少一個(gè)從庫(kù)寫(xiě)入 Relay Log 后，并將數(shù)據(jù)落盤(pán)，然后返回給主庫(kù) ACK，通知主庫(kù)可以執(zhí)行 commit 操作，然后主庫(kù)再將事務(wù)提交到事務(wù)引擎層，應(yīng)用此時(shí)才可以看到數(shù)據(jù)發(fā)生了變化。

當(dāng)然之前的半同步方案同樣支持，MySQL 5.7.2 引入了一個(gè)新的參數(shù) rpl_semi_sync_master_wait_point 進(jìn)行控制。這個(gè)參數(shù)有兩種取值：

1. AFTER_SYNC：這個(gè)是新的半同步方案，Waiting Slave dump 在 Storage Commit 之前。

2. AFTER_COMMIT：這個(gè)是老的半同步方案。

在 MySQL 5.5 - 5.6 使用 after_commit 的模式下，客戶端事務(wù)在存儲(chǔ)引擎層提交后，在主庫(kù)等待從庫(kù)確認(rèn)的過(guò)程中，主庫(kù)宕機(jī)了。此時(shí)，結(jié)果雖然沒(méi)有返回給當(dāng)前客戶端，但事務(wù)已經(jīng)提交了，其他客戶端會(huì)讀取到該已提交的事務(wù)。如果從庫(kù)沒(méi)有接收到該事務(wù)或者未寫(xiě)入 relay log，同時(shí)主庫(kù)宕機(jī)了，之后切換到備庫(kù)，那么之前讀到的事務(wù)就不見(jiàn)了，出現(xiàn)了幻讀，也就是數(shù)據(jù)丟失了。

MySQL 5.7 默認(rèn)值則是 after_sync，主庫(kù)將每個(gè)事務(wù)寫(xiě)入 binlog，傳給從庫(kù)并刷新到磁盤(pán) (relay log)。主庫(kù)等到從庫(kù)返回 ack 之后，再提交事務(wù)并且返回 commit OK 結(jié)果給客戶端。 即使主庫(kù) crash，所有在主庫(kù)上已經(jīng)提交的事務(wù)都能保證已經(jīng)同步到從庫(kù)的 relay log 中，解決了 after_commit 模式帶來(lái)的幻讀和數(shù)據(jù)丟失問(wèn)題，故障切換時(shí)數(shù)據(jù)一致性將得到提升。因?yàn)閺膸?kù)沒(méi)有寫(xiě)入成功的話主庫(kù)也不會(huì)提交事務(wù)。并且在 commit 之前等待從庫(kù) ACK，還可以堆積事務(wù)，有利于 group commit 組提交，有利于提升性能。

但這樣也會(huì)有個(gè)問(wèn)題，假設(shè)主庫(kù)在存儲(chǔ)引擎提交之前掛了，那么很明顯這個(gè)事務(wù)是不成功的，但由于對(duì)應(yīng)的 Binlog 已經(jīng)做了 Sync 操作，從庫(kù)已經(jīng)收到了這些 Binlog，并且執(zhí)行成功，相當(dāng)于在從庫(kù)上多了數(shù)據(jù)（從庫(kù)上有該數(shù)據(jù)而主庫(kù)沒(méi)有），也算是有問(wèn)題的，但多了數(shù)據(jù)一般不算嚴(yán)重的問(wèn)題。它能保證的是不丟數(shù)據(jù)，多了數(shù)據(jù)總比丟數(shù)據(jù)要好。

一主多從

如果從庫(kù)承擔(dān)了大量查詢請(qǐng)求，那么從庫(kù)上的查詢操作將耗費(fèi)大量的 CPU 資源，從而影響了同步速度，造成主從延遲。那么我們可以多接幾個(gè)從庫(kù)，讓這些從庫(kù)來(lái)共同分擔(dān)讀的壓力。

簡(jiǎn)而言之，就是加機(jī)器，方法簡(jiǎn)單粗暴，但也會(huì)帶來(lái)一定成本。

強(qiáng)制走主庫(kù)方案

如果某些操作對(duì)數(shù)據(jù)的實(shí)時(shí)性要求比較苛刻，需要反映實(shí)時(shí)最新的數(shù)據(jù)，比如說(shuō)涉及金錢(qián)的金融類(lèi)系統(tǒng)、在線實(shí)時(shí)系統(tǒng)、又或者是寫(xiě)入之后馬上又讀的業(yè)務(wù)，這時(shí)我們就得放棄讀寫(xiě)分離，讓此類(lèi)的讀請(qǐng)求也走主庫(kù)，這就不存延遲問(wèn)題了。

當(dāng)然這也失去了讀寫(xiě)分離帶給我們的性能提升，需要適當(dāng)取舍。

并行復(fù)制

一般 MySQL 主從復(fù)制有三個(gè)線程參與，都是單線程：Binlog Dump 線程、IO 線程、SQL 線程。復(fù)制出現(xiàn)延遲一般出在兩個(gè)地方：

• SQL 線程忙不過(guò)來(lái)（主要原因）；

• 網(wǎng)絡(luò)抖動(dòng)導(dǎo)致 IO 線程復(fù)制延遲（次要原因）。

日志在備庫(kù)上的執(zhí)行，就是備庫(kù)上 SQL 線程執(zhí)行中繼日志（relay log）更新數(shù)據(jù)的邏輯。

在 MySQL 5.6 版本之前，MySQL 只支持單線程復(fù)制，由此在主庫(kù)并發(fā)高、TPS 高時(shí)就會(huì)出現(xiàn)嚴(yán)重的主備延遲問(wèn)題。從 MySQL 5.6 開(kāi)始有了多個(gè) SQL 線程的概念，可以并發(fā)還原數(shù)據(jù)，即并行復(fù)制技術(shù)。這可以很好的解決 MySQL 主從延遲問(wèn)題。

從單線程復(fù)制到最新版本的多線程復(fù)制，中間的演化經(jīng)歷了好幾個(gè)版本。其實(shí)說(shuō)到底，所有的多線程復(fù)制機(jī)制，都是要把只有一個(gè)線程的 sql_thread，拆成多個(gè)線程，也就是都符合下面的這個(gè)多線程模型：

coordinator 就是原來(lái)的 sql_thread，不過(guò)現(xiàn)在它不再直接更新數(shù)據(jù)了，只負(fù)責(zé)讀取中轉(zhuǎn)日志和分發(fā)事務(wù)。真正更新日志的，變成了 worker 線程。而 worker 線程的個(gè)數(shù)，就是由參數(shù) slave_parallel_workers 決定的。

由于 worker 線程是并發(fā)運(yùn)行的，為了保證事務(wù)的隔離性以及不會(huì)出現(xiàn)更新覆蓋問(wèn)題，coordinator 在分發(fā)的時(shí)候，需要滿足以下這兩個(gè)基本要求：

1. 更新同一行的兩個(gè)事務(wù)，必須被分發(fā)到同一個(gè) worker 中（避免更新覆蓋）。

2. 同一個(gè)事務(wù)不能被拆開(kāi)，必須放到同一個(gè) worker 中（保證事務(wù)隔離性）。

各個(gè)版本的多線程復(fù)制，都遵循了這兩條基本原則。

以下是按表分發(fā)策略和按行分發(fā)策略，可以幫助理解 MySQL 官方版本并行復(fù)制策略的迭代：

• 按表分發(fā)策略：如果兩個(gè)事務(wù)更新不同的表，它們就可以并行。因?yàn)閿?shù)據(jù)是存儲(chǔ)在表里的，所以按表分發(fā)，可以保證兩個(gè) worker 不會(huì)更新同一行。

• 按表分發(fā)的方案，在多個(gè)表負(fù)載均勻的場(chǎng)景里應(yīng)用效果很好，但缺點(diǎn)是：如果碰到熱點(diǎn)表，比如所有的更新事務(wù)都會(huì)涉及到某一個(gè)表的時(shí)候，所有事務(wù)都會(huì)被分配到同一個(gè) worker 中，就變成單線程復(fù)制了。

• 按行分發(fā)策略：如果兩個(gè)事務(wù)沒(méi)有更新相同的行，則它們?cè)趥鋷?kù)上可以并行。顯然，這個(gè)模式要求 binlog 格式必須是 row。

• 按行并行復(fù)制的方案解決了熱點(diǎn)表的問(wèn)題，并行度更高，但缺點(diǎn)是：相比于按表并行分發(fā)策略，按行并行策略在決定線程分發(fā)的時(shí)候，需要消耗更多的計(jì)算資源。

MySQL 5.6 版本的并行復(fù)制策略

MySQL 5.6 版本，支持了并行復(fù)制，只是支持的粒度是按庫(kù)并行（基于 Schema）。

其核心思想是：不同 schema 下的表并發(fā)提交時(shí)的數(shù)據(jù)不會(huì)相互影響，即從庫(kù)可以對(duì) relay log 中不同的 schema各分配一個(gè)類(lèi)似 SQL 線程功能的線程，來(lái)重放 relay log 中主庫(kù)已經(jīng)提交的事務(wù)，保持?jǐn)?shù)據(jù)與主庫(kù)一致。

如果在主庫(kù)上有多個(gè) DB，使用這個(gè)策略對(duì)于從庫(kù)復(fù)制的速度可以有比較大的提升。但通常情況下都是單庫(kù)多表，那基于庫(kù)的并發(fā)也就沒(méi)有什么作用，根本無(wú)法并行重放，所以這個(gè)策略用得并不多。

MySQL 5.7 的并行復(fù)制策略

MySQL 5.7 引入了基于組提交的并行復(fù)制，參數(shù) slave_parallel_workers 設(shè)置并行線程數(shù)，由參數(shù) slave-parallel-type 來(lái)控制并行復(fù)制策略：

• 配置為 DATABASE，表示使用 MySQL 5.6 版本的按庫(kù)并行策略；

• 配置為 LOGICAL_CLOCK，表示使用基于組提交的并行復(fù)制策略；

利用 binlog 的組提交 (group commit) 機(jī)制，可以得出一個(gè)組提交的事務(wù)都是可以并行執(zhí)行的，原因是：能夠在同一組里提交的事務(wù)，一定不會(huì)修改同一行（由于 MySQL 的鎖機(jī)制），因?yàn)槭聞?wù)已經(jīng)通過(guò)鎖沖突的檢驗(yàn)了。

基于組提交的并行復(fù)制具體流程如下：

1. 在一組里面一起提交的事務(wù)，有一個(gè)相同的 commit_id，下一組就是 commit_id+1；commit_id 直接寫(xiě)到 binlog 里面；

2. 傳到備庫(kù)應(yīng)用的時(shí)候，相同 commit_id 的事務(wù)分發(fā)到多個(gè) worker 執(zhí)行；

3. 這一組全部執(zhí)行完成后，coordinator 再去取下一批執(zhí)行。

所有處于 prepare 和 commit 狀態(tài)的事務(wù)都是可以在備庫(kù)上并行執(zhí)行的。

binlog 的組提交的兩個(gè)有關(guān)參數(shù)：

• binlog_group_commit_sync_delay 參數(shù)，表示延遲多少微秒后才調(diào)用 fsync 刷盤(pán)；

• binlog_group_commit_sync_no_delay_count 參數(shù)，表示累積多少次以后才調(diào)用 fsync。

這兩個(gè)參數(shù)是用于故意拉長(zhǎng) binlog 從 write 到 fsync 的時(shí)間，以此減少 binlog 的寫(xiě)盤(pán)次數(shù)。在 MySQL 5.7 的并行復(fù)制策略里，它們可以用來(lái)制造更多的“同時(shí)處于 prepare 階段的事務(wù)”。可以考慮調(diào)整這兩個(gè)參數(shù)值，來(lái)達(dá)到提升備庫(kù)復(fù)制并發(fā)度的目的。

到此，相信大家對(duì)“MySQL主從延遲問(wèn)題怎么解決”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

標(biāo)題名稱：MySQL主從延遲問(wèn)題怎么解決
文章地址：http://www.chinadenli.net/article2/ishpic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、虛擬主機(jī)、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、動(dòng)態(tài)網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)公司

廣告

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