寫在前面：

10年積累的做網(wǎng)站、網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先建設(shè)網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有和布克賽爾蒙古免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

之前在維護線上主從復(fù)制架構(gòu)的時候，遇到了一些主從延遲問題，筆者呢，也是比較好學(xué)的，哈哈！所以，查閱了諸多資料，然后去其糟粕，根據(jù)自己的理解和查閱的資料整理成了本文，在此申明，本文內(nèi)容是筆者自己的理解，不代表權(quán)威性，僅供各位同行做個參考，自己呢，也做個學(xué)習(xí)記錄。本著實事求是的原則，對于網(wǎng)上的諸多資料，筆者自己也只是信5分，懷疑5分，就算是官方的資料，有的也有bug不是，只有自己動手實踐過了，才能相信，才有發(fā)言權(quán)，其他的，一切都是虛的！

MySQL主從復(fù)制過程：

1）主庫 Binlog Dump線程在binlog有變化時，主動發(fā)送最新的binlog到從庫。

2）從庫 I/O線程被動接收主庫傳來的binlog之后，記錄到從庫的relay log中，當(dāng)沒有數(shù)據(jù)傳入的時候則會等待。與此同時SQL線程重放 relay log。

3）當(dāng)從庫長時間未收到主庫傳來的數(shù)據(jù)，并且等待時間超過了slave_net_timeout定義的時間（默認3600秒）后，Slave_IO_State的狀態(tài)將會置為No。在此之后，每隔MASTER_CONNECT_RETRY [Connect_Retry: 30]定義的時間（默認60秒）將會嘗試重新連接，直到連接成功或超過重試次數(shù)MASTER_RETRY_COUNT [Master_Retry_Count: 6666]（默認86400次）。

slave_net_timeout可以在配置文件中修改或set variable在線設(shè)置

而 MASTER_CONNECT_RETRY、MASTER_RETRY_COUNT 需要在CHANGE MASTER TO建立復(fù)制關(guān)系時提前指定

在線變更 slave_net_timeout：

SHOW VARIABLES LIKE 'slave_net_timeout'

Variable_name????????? `Value`

slave_net_timeout???? ?3600

SET GLOBAL slave_net_timeout=1800

修改MASTER_CONNECT_RETRY=30,MASTER_RETRY_COUNT值：

mysql> change master to MASTER_CONNECT_RETRY=30,MASTER_RETRY_COUNT=6666;

ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE first

mysql> stop slave;

Query OK, 0 rows affected (0.01 sec)

mysql> change master to MASTER_CONNECT_RETRY=30,MASTER_RETRY_COUNT=6666;

Query OK, 0 rows affected (0.01 sec)

mysql> start slave;

Query OK, 0 rows affected (0.02 sec)

MySQL主從復(fù)制延遲是怎樣形成的：

1、主庫的worker線程在寫binlog的時候是并發(fā)工作的（并行寫入），而主庫的dump線程和從庫的IO線程都是單線程推拉binlog，特別是SQL線程是拿著relay log中的event逐一單線程回放的（5.6版本開啟slave_parallel_workers支持特定情況下的并行復(fù)制，5.7版本之后全面支持并行復(fù)制后在復(fù)制層面已極大改善了延遲問題）。因此即使不考慮網(wǎng)絡(luò)延遲，主流MySQL版本在高并發(fā)的情況下，消費很可能趕不上生產(chǎn)，采用異步復(fù)制的從庫很有可能跟不上主庫的進度。

2、在復(fù)制期間，無論是主庫或從庫負載高（特別是從庫落盤壓力大，關(guān)系到sync_binlog、innodb_flush_log_at_trx_commit的設(shè)置）或者是網(wǎng)絡(luò)傳輸慢（特別是跨機房的同步）等情況發(fā)生時，都會產(chǎn)生主從延遲，并且是不可避免的。如果要實現(xiàn)強一致性，可采用Semi-sync，但采用該plugin也無法保證持續(xù)強一致性（rpl_semi_sync_master_timeout會引起復(fù)制模式的降級）

根據(jù)MySQL主從復(fù)制延遲的形成原因，以下情況可能導(dǎo)致MySQL主從復(fù)制延遲：

1）MASTER高并發(fā)，形成大量事務(wù)

2）網(wǎng)絡(luò)狀況差

3）從庫的硬件配置沒有主庫的好

4）本來就是異步復(fù)制

關(guān)于落盤時的部分參數(shù)解釋：

sync_binlog：

MySQL官方文檔參考：https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html

解釋：

Controlshow often the MySQL server synchronizes the binary log to disk

控制MySQL將二進制日志（binary log）同步到磁盤的頻率

sync_binlog=0:

Disables synchronization of the binary log to disk by the MySQL server. Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log.

sync_binlog=1:

Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.

sync_binlog=N:

where N is a value other than 0 or 1: The binary log is synchronized to disk after N binary log commit groups have been collected. In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data loss.

innodb_flush_log_at_trx_commit：

MySQL官方文檔參考：https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

其他參考文檔：

????https://blog.csdn.net/codepen/article/details/52160715

https://www.cnblogs.com/mayipapa/p/4685313.html

解釋：

是 InnoDB 引擎特有的，ib_logfile的刷新方式

MySQL日志寫入順序：

log buffer => MySQL(write) => log file => OS刷新(flush) => disk

innodb_flush_log_at_trx_commit取值解釋：（從一些博客之中參考的）

0，延遲寫：

log buffer => 每隔1秒 => log file => OS 實時flush => disk

1，實時寫，實時刷：

log buffer => 實時 => log file => OS實時flush => disk

這樣的話，數(shù)據(jù)庫對IO的要求就非常高了，如果底層的硬件提供的IOPS比較差，那么MySQL數(shù)據(jù)庫的并發(fā)很快就會由于硬件IO的問題而無法提升

2，實時寫，延遲刷：

log buffer => 實時 => log file => OS每隔1秒 => disk

如果只是MySQL數(shù)據(jù)庫掛掉了，由于文件系統(tǒng)沒有問題，那么對應(yīng)的事務(wù)數(shù)據(jù)并沒有丟失。只有在數(shù)據(jù)庫所在的主機操作系統(tǒng)損壞或者突然掉電的情況下，數(shù)據(jù)庫的事務(wù)數(shù)據(jù)可能丟失1秒之類的事務(wù)數(shù)據(jù)。這樣的好處，減少了事務(wù)數(shù)據(jù)丟失的概率，而對底層硬件的IO要求也沒有那么高(log buffer寫到文件系統(tǒng)中，一般只是從log buffer的內(nèi)存轉(zhuǎn)移的文件系統(tǒng)的內(nèi)存緩存中，對底層IO沒有壓力)。

官方文檔中文解釋：（筆者自己的理解）

當(dāng)innodb_flush_log_at_trx_commit，被設(shè)置為0，日志緩沖(log buffer)每秒一次地被寫入到日志文件(log file)，并且對日志文件做磁盤刷新(flush disk)，該模式下在事務(wù)提交的時候，不會主動觸發(fā)寫入磁盤的操作。

當(dāng)innodb_flush_log_at_trx_commit，被設(shè)置為1，在每個事務(wù)提交時，日志緩沖(log buffer)被寫入到日志文件(log file)，并且對日志文件做磁盤刷新(flush disk) [同時進行]

當(dāng)innodb_flush_log_at_trx_commit，被設(shè)置為2，在每個事務(wù)提交時，日志緩沖(log buffer)被寫入到日志文件(log file)，但不對日志文件做磁盤刷新(flush disk) [不同時進行]，該模式下，MySQL會每秒執(zhí)行一次 flush(刷到磁盤)操作

? ?? 盡管如此，當(dāng)innodb_flush_log_at_trx_commit值為2時，對日志文件(log file)的磁盤刷新(flush disk)也每秒發(fā)生一次。

因為進程安排問題，每秒一次的刷新不是100%保證都會發(fā)生?？梢酝ㄟ^設(shè)置innodb_flush_log_at_trx_commit值不為1來獲得較好的性能，但如果你設(shè)置此值為0，那么MySQL崩潰會丟失崩潰前1秒的事務(wù)（該模式下性能最好，但不×××全）；如果設(shè)置此值為2，當(dāng)操作系統(tǒng)崩潰或斷電時才會丟失最后1秒的事務(wù)（該模式下性能較好，也比0模式安全）。如果設(shè)置此值為0，該模式性能最低，但是最安全的模式。在MySQL服務(wù)崩潰或者操作系統(tǒng)crash的情況下，binlog只會丟失一個語句或一個事務(wù)。

注意，許多操作系統(tǒng)和一些磁盤硬件會欺騙刷新到磁盤操作(flush disk)。盡管刷新沒有進行，也會告訴MySQL刷新已經(jīng)進行。即使設(shè)置此值為1，事務(wù)的持久性也不被保證，且在最壞的情況下斷電甚至?xí)茐臄?shù)據(jù)庫。在SCSI磁盤控制器中，或在磁盤自身中，使用有后備電池的磁盤緩存會加速文件刷新并且使得操作更安全?？梢栽囍褂胔dparm命令在硬件緩存中禁止磁盤寫緩存，或者使用其他一些對硬件提供商專用的命令

最后MySQL官方建議：

A higher value improves performance, but with an increased risk of data loss

For the greatest possible durability and consistency in a replication setup that uses InnoDB with transactions, use these settings:

sync_binlog=1

innodb_flush_log_at_trx_commit=1

MySQL主從延遲如何計算：

第一種計算方式：position（簡單粗暴，僅僅能看出是否有延遲）

mysql> show slave status\G;

Read_Master_Log_Pos: 4

Exec_Master_Log_Pos: 0

第二種計算方式：Seconds_Behind_Master

參考MySQL官方文檔：

https://dev.mysql.com/doc/refman/5.6/en/replication-administration-status.html

https://dev.mysql.com/doc/refman/5.6/en/show-slave-status.html

參考其他文章：

https://blog.csdn.net/leonpenn/article/details/76489480

1） 當(dāng)SQL線程執(zhí)行event時，從庫執(zhí)行時刻的timestamp值 減去 該event上附帶的時間戳（當(dāng)時主庫上的timestamp），這兩者的差值

2） 一旦SQL線程未在執(zhí)行event，則Seconds_Behind_Master為0

3） IO線程或SQL線程 is?not?running，則Seconds_Behind_Master為NULL

4） Seconds_Behind_Master為0時，表示master slave 復(fù)制沒有延遲（絕大情況下如此）

在網(wǎng)絡(luò)很快的情況下，io thread 很快的從master獲取binlog到slave的realy log，然后sql thread replay，此時Seconds_Behind_Master值能真正表示slave落后于master的秒數(shù)。

在網(wǎng)絡(luò)很差的情況下，io thread同步master的binlog很慢，而sql thread replay很快，此時Seconds_Behind_Master也是0，但真正情況是，slave落后于master很多

假如有以下3種情況發(fā)生，雖然Seconds_Behind_Master仍然存在非NULL的值，但已經(jīng)變得不準確

1、主從時間不一致（雖然引入了clock_diff_with_master，盡量調(diào)節(jié)時間差帶來的影響，但該值僅在從庫與主庫建立連接之時獲取，后續(xù)不再更新，若之后再去修改主從機的時間，該值就不可靠了）。

2、主從庫間網(wǎng)絡(luò)問題或者從庫IO線程未發(fā)現(xiàn)主庫的binlog dump 線程掛了，仍然在等待數(shù)據(jù)傳輸過來，SBM長時間持續(xù)為零。

3、主庫有較大的binlog event執(zhí)行前后，從庫上看到的SBM將會有大的跳動（監(jiān)控圖中將很可能產(chǎn)生毛刺）

4、對于并行復(fù)制，SMB是基于Exec_Master_Log_Pos，不精準。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：主從復(fù)制延遲原因剖析！-創(chuàng)新互聯(lián)
文章來源：http://chinadenli.net/article30/eojpo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、品牌網(wǎng)站制作、ChatGPT、網(wǎng)站排名、手機網(wǎng)站建設(shè)、軟件開發(fā)

廣告

聲明：本網(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)