MYSQL從節點延遲問題原因及處理方法

mysql 因為異步同步，只能達到最終一致性，而無法達到實時一致性，所以理論是有延遲在所難免。
在mysql 5.7 版本實現了多線程同步，緩解了延遲問題，但不可能完全實現實時同步。

一、延遲原因大概有以下幾點：

1.硬件
問題主要體現在服務器性能問題上，服務器性能包括主節點和從節點。
MYSQL 同步如果配置成 binlog_format=row,從節點一般會從節點性能優于主節點。
如果是多源復制，那么從節點的性能高于主節點就尤為重要。
主要是以下幾個方面：

1. CPU,MEM 2. 網絡 3. 磁盤

---

2.參數配置
（這里不討論MYSQL 性能相關參數，只列出以主從同步相關的一些參數。）
影響主從同步參數羅列如下：

#關閉binlog 日志，從節點不寫日志， 減少IO。 #log-bin = /data/mysql/mysql-bin #binlog_format=row #如果不需要緊急備份還原從節點的話，可以關掉slave的二進制文件記錄功能---------------------- sync_binlog = 0 innodb_flush_log_at_trx_commit = 0參數解析如下： sync_binlog = N N=0 不主動刷新二進制日志文件的數據到磁盤上，而是由操作系統決定；innodb_flush_log_at_trx_commit = N： N=0 每隔一秒，把事務日志緩存區的數據寫到日志文件中，以及把日志文件的數據刷新到磁盤上； log buffer 會每秒寫入到日志文件并刷寫（flush）到磁盤。但每次事務提交不會有任何影響， 也就是 log buffer 的刷寫操作和事務提交操作沒有關系。 在這種情況下，MySQL性能最好，但如果 mysqld 進程崩潰，通常會導致最后 1s 的日志丟失N=0,0 磁盤IO寫能力有限，無復制或允許復制延遲稍微長點能接受，例如：日志性登記業務；------------------------ sync_master_info = 1 sync_relay_log=0 sync_relay_log_info = 0sync_master_info：每間隔多少事務刷新master.info，如果是table（innodb）設置無效，每個事務都會更新 sync_relay_log：默認為10000，即每10000次sync_relay_log事件會刷新到磁盤。為0則表示不刷新，交由OS的cache控制 sync_relay_log_info：每間隔多少事務刷新relay-log.info，如果是table（innodb）設置無效，每個事務都會更新---------------------- log_slave_updates=0 #關閉log_slave_updates，從庫【binlog】不再記錄主庫同步的操作日志到binlog--------------------------------- #同步線程設置 slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=18 #配置自己需要的線程數------------------------- long_query_time = 2 slow_query_log = 1 log_slow_slave_statements = 1 slow_query_log_file = /data/mysql/slow.log #打開慢查詢，慢查詢時間限制是2秒。

---

3.主節點中運行的大事務

大批量的插入，修改，刪除數據。因為日志格式為binlog_format=row，會產生大量的binlog 日志。 大事務處理，也是批量提交更新，也是有時間延遲的。

---

4.主節點、從節點的慢查詢影響

慢查詢會影響MYSQL性能，有鎖等待。以至于數據的更新存在時間差。在從節點體現為：io等待，鎖等待。

5.主節點數據鎖問題

比如表修改： alter table,create index 這類表級鎖，直接產生等待。 就是一般的 update 如果修改數據量大，也會影響到從節點的同步。

6.主節點中表無主鍵
如果一個表沒有主鍵，在同步到從節點后，所有的修改，每次的查詢都是全表搜索，性能差問題被廣大。
（比如更新100條記錄，每條記錄更新都是一個binlog事務,每次更新都是全表搜索）

---

前面說了出現延遲的原因，現在來看看怎樣解決：

二.定位同步延遲

在主從節點中，使用以下命令，可以看到以下一些信息：主節點：show master status\GMaster file:mysql-bin.000010 Master Position:144033539從節點： show slave status\GSlave_IO_State: Waiting for master to send eventMaster_Host: 10.10.1.161Master_User: bakMaster_Port: 3301Connect_Retry: 60Master_Log_File: mysql-bin.000010 #主從節點同步的文件是一致的Read_Master_Log_Pos: 144033539 #讀到的日志位置點也是一致的，說明主從IO同步日志沒有問題，也就是說問題不在IO_threadRelay_Log_File: test-mysql02-relay-bin-master1.000042Relay_Log_Pos: 77469816Relay_Master_Log_File: mysql-bin.000010Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: Replicate_Ignore_DB: mysql,information_schema,performance_schema,sys,batchReplicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 144032167 #重新解析日志的位置點嚴重滯后，說明問題在 sql_thread Seconds_Behind_Master: 1 #延遲時間（最小單位1秒，但這個并不是很準確的） 1.從上面的分析可以定位到問題在 sql_thread，也就是說問題在從節點上。 有可能是性能問題，比如：MEM 不足，IO性能差。 計劃先修改參數值，進行調整。2.如果 Read_Master_Log_Pos 189460063 值與主節點 Position 1030784024 相關太大。問題應該是出在網絡上，主從同步日志文件太慢。 3.如果 Relay_Log_Pos: 171735369 值 Exec_Master_Log_Pos: 171735164 相關太大，問題應該是在磁盤IO，或者服務器本身性能問題，重解析日志時，讀取日志到 執行SQL時間太長 。2.如果前面的定位發現是IO_thread 問題（日志不同步，讀到的日志位置不一致）。我們可以從網絡方面解決。 2.1.查看網絡帶寬， 2.2.使用壓縮傳輸：主從日志傳輸進行壓縮傳輸：slave_compressed_protocol=1mysql> show variables like 'slave_compressed_protocol';+---------------------------+-------+| Variable_name | Value |+---------------------------+-------+| slave_compressed_protocol | OFF |+---------------------------+-------+1 row in set (0.00 sec)我得到上面的預警信息是使用了以下腳本:#!/bin/shcmd=/usr/local/mysql/bin/mysqlmysqluser=testmysqlpwd=testpsdlog=/opt/shell/slave_monitor.loghosts='10.10.1.101'master_host='10.10.1.10'm_port='3306'behind=`$cmd -u$mysqluser -p$mysqlpwd -e "show slave status\G"|grep -iE "Seconds_Behind_Master"|awk '{print $2}'`m_file=`$cmd -h${master_host} -utest -ptest --port ${m_port} -e "show master status\G"|grep -iE "File"|awk '{print $2}'`m_position=`$cmd -h${master_host} -utest -ptest --port ${m_port} -e "show master status\G"|grep -iE "Position"|awk '{print $2}'`s_status=`$cmd -u$mysqluser -p$mysqlpwd -e "show slave status for channel 'master1'\G"|sed -n 1,23p `if [ "$behind1" -gt 0 ] then DingTalk.py "$master_host:Seconds_Behind_Master：$behind. Master file:$m_file Master Position:$m_position $s_status"fi3.打開慢查詢跟蹤，查看具體是什么SQL 很慢,逐個SQL 進行優化。mysql> show variables like 'log_slow_slave_statements';+---------------------------+-------+| Variable_name | Value |+---------------------------+-------+| log_slow_slave_statements | OFF |+---------------------------+-------+1 row in set (0.00 sec)mysql> 4.某些表缺少主鍵或者唯一鍵則所有的SQL_THREAD會掃描全表并造成同步延遲。 所以需要確保表有主鍵或者唯一鍵。以下SQL 可查詢是否有表沒有主鍵索引：mysql> select TABLE_SCHEMA,TABLE_NAME from `information_schema`.`columns` c where TABLE_SCHEMA='hyjf_config' GROUP BY TABLE_SCHEMA,TABLE_NAME HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

總結

以上是生活随笔為你收集整理的MYSQL从节点延迟问题原因及解决的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。