Mysql複製落後Update_rows_log_event :: ha_update_row（-1）

我管理（從這裏獲得一些幫助）從運行mysql 5.6（centos 6）的MASTER服務器到運行Mariadb 10.1.22（Centos 7 ）。Mysql複製落後Update_rows_log_event :: ha_update_row（-1）

現在我的問題是這個，我有另一臺服務器與確切mariadb版本和規格，但其複製沒有趕上，而是在增加。

開始時，它落後了48000秒，幾分鐘後迅速降至46000秒。之後，它正在穩步增長。自動櫃員機的寫作幾乎回到48K秒

Show full processlist;顯示SQL線程花費高達8秒運行Update_rows_log_event::ha_update_row(-1)背靠背從哪裏來的所有谷歌搜索我找不到它的意思。

MariaDB [(none)]> show full processlist; 
+-----+------------------+---------------------------------------+--------------+---------+------+------------------------------------------+-----------------------+----------+ 
| Id | User    | Host         | db   | Command | Time | State         | Info     | Progress | 
+-----+------------------+---------------------------------------+--------------+---------+------+------------------------------------------+-----------------------+----------+ 
| 3 | system user  |          | NULL   | Connect | 3640 | Queueing master event to the relay log | NULL     | 0.000 | 
| 2 | system user  |          | NULL   | Connect | 5 | Update_rows_log_event::ha_update_row(-1) | NULL     | 0.000 |

另外我抓住一個簡單UPDATE table SET timestamp = NOW() WHERE static_ip = 'a-valid-ip' AND process_id = '13217'服用多達6秒，同時表具有STATIC_IP和PROCESS_ID列作爲PK和當直接執行所述命令纔會0.078秒。

的/etc/my.cnf

[mysqld] 
max_allowed_packet = 1G 
max_connections = 600 
thread_cache_size = 16 
query_cache_size = 64M 
tmp_table_size= 512M 
max_heap_table_size= 512M 
wait_timeout=60 

#Innodb Settings 
innodb_file_per_table=1 
innodb_buffer_pool_size = 25G 
innodb_log_file_size = 2048M 
innodb_flush_log_at_trx_commit = 0 
innodb_file_format = Barracuda 
innodb_flush_neighbors = 0 

#Log 

log-error =/var/log/error.log 
tmpdir = /dev/shm 


#Replication SLAVE 

server-id=6 
slave-skip-errors=1062

my.cnf中的內容是一樣的，不同之處是針對從ID OK運行的服務器。

關於發生了什麼的任何建議/幫助？

謝謝。

來源

2017-04-06 Thomas Nikoleris

編輯1 *。仍落後發現一個未解決的問題，類似於我的問題http://serverfault.com/questions/407535/queries-stuck-on-the-connect-command，但我的表是innoDB，並沒有選擇查詢運行此數據庫。 –

GTID關閉了嗎？請提供'SHOW SLAVE STATUS;' –

請提供'SHOW CREATE TABLE'。 –

在mariadb的幫助下，ha_update_rows與此無關，緩慢的原因是機器出現雙磁盤故障。

[[email protected] ~]# dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB) copied, 43.1096 s, 9.3 MB/s

這是SSD。

來源

2017-04-07 00:50:24

Mysql複製落後Update_rows_log_event :: ha_update_row（-1）

回答

相關問題