2011-12-17 90 views
10

我的MySql數據庫有一個主/從複製。MySql複製 - 從站落後於主

我的奴隸DB被關閉了幾個小時,然後又重新備份(主人一直在上),當發出show slave status時,我可以看到奴隸在主人後面X秒。

的問題是,從似乎沒有趕上師傅,師傅身後的X秒不似乎下降...

我如何能幫助從追趕什麼想法?

+0

你有鎖定表嗎? – 2011-12-17 21:01:24

+0

不是我所知道的 – Ran 2011-12-17 21:06:40

+0

最終奴隸會趕上,除非你有大量的查詢,如更新和插入主人。你有很多來自服務器的查詢嗎? – 2011-12-17 21:14:43

回答

13

這是一個想法

爲了讓你知道MySQL正在從中繼日誌中完全處理SQL。請嘗試以下操作:

STOP SLAVE IO_THREAD; 

這將停止從主站下載新條目到其中繼日誌的複製。

另一個線程,被稱爲SQL線程,將繼續處理它從主機下載的SQL語句。

當您運行SHOW SLAVE STATUS\G,不斷Exec_Master_Log_Pos你的眼睛。再次運行SHOW SLAVE STATUS\G。如果Exec_Master_Log_Pos一分鐘後不動,可以繼續運行START SLAVE IO_THREAD;。這可能會減少Seconds_Behind_Master的數量。

除此之外,實在沒有什麼可以除了做:

  • 信託複製
  • 監視器Seconds_Behind_Master
  • 監視器Exec_Master_Log_Pos
  • 運行SHOW PROCESSLIST;,請注意SQL線程來看看如果它正在處理長時間運行的查詢。

記住BTW記住,當你複製運行運行SHOW PROCESSLIST;,應該有兩個數據庫連接,其用戶名是system user。其中一個數據庫連接將使當前的SQL語句被複制處理。只要每次運行SHOW PROCESSLIST;時都可以看到不同的SQL語句,則可以信任mysql仍在正確複製。

+0

有點奇怪,但停止線程並沒有幫助我,而是監視Exec_Master_Log_Pos和來自系統用戶的兩個連接讓我不會嚇壞了。重新啓動從站後,一切都恢復正常。感謝羅蘭多。 – 2017-02-10 20:01:37

3

「秒後」不是一個非常好的工具,可以找出你真正的主人背後有多少。它說的是「我剛剛執行的查詢是在X秒前在主服務器上執行的」。這並不意味着你會在下一秒趕上主人。

如果你的奴隸通常不落後,主人的工作負荷大致不變,你會趕上,但它可能需要一些時間,如果奴隸通常只是幾乎沒有跟上,它甚至可能需要「永遠」與主人。從設備在一個單線程上運行,因此它的設計在設計上要比主設備慢得多,而且如果有一些查詢在主設備上需要一段時間,它們將在從設備上運行時阻止複製。

1

只是檢查,如果你有相同的時間和兩個服務器上的時區,即主以及奴隸。

6

你使用什麼二進制日誌格式?你在使用ROW還是STATEMENT?

SHOW GLOBAL VARIABLES LIKE 'binlog_format'; 

如果您正在使用的行作爲一個二進制日誌格式,請確保所有表具有原發性或唯一鍵:

SELECT t.table_schema,t.table_name,engine 
FROM information_schema.tables t 
INNER JOIN information_schema .columns c 
on t.table_schema=c.table_schema 
and t.table_name=c.table_name 
and t.table_schema not in ('performance_schema','information_schema','mysql') 
GROUP BY t.table_schema,t.table_name 
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0; 

如果執行例如一個刪除語句在主服務器上刪除一個沒有PK或唯一密鑰的表上的一百萬條記錄,那麼只有一個全表掃描將在主服務器端發生,而從服務器則不是這種情況。

當使用ROW binlog_format時,MySQL將行更改寫入二進制日誌(不像STATEMENT binlog_format這樣的語句),並且該更改將逐行應用於從屬端,這意味着一個100萬的全表掃描將發生在從屬設備上,以反映主設備上只有一條刪除語句,並導致從設備滯後問題。

0

我們從最近的備份設置了站後有完全一樣的問題。

我們已經改變了我們的奴隸的配置更加碰撞安全:

sync_binlog = 1 
sync_master_info = 1 
relay_log_info_repository = TABLE 
relay_log_recovery = 1 

我認爲,特別是sync_binlog = 1導致問題,因爲這從設備的規格是不會這麼快在大師。這個配置選項強制從機在執行之前將每個事務存儲在二進制Lo中(而不是每10k次事務的默認值)。

將這些配置選項再次禁用爲默認值後,我發現從站正在重新啓動。

0

只需在我的類似案例中添加調查結果即可。

在從站中的中繼日誌佔用大部分空間的主站發生了大量的臨時表插入/更新/刪除。在Mysql 5.5中,由於是單線程的,CPU始終處於100%的狀態,並花費大量時間來處理這些記錄。

我所做的就是在mysql的CNF文件

replicate-ignore-table=<dbname>.<temptablename1> 
replicate-ignore-table=<dbname>.<temptablename2> 

添加這些行,一切又變得光滑。

爲了弄清楚哪些表在繼電器日誌中佔用更多空間,請嘗試以下命令,然後在文本編輯器中打開。你可能會得到一些提示

cd /var/lib/mysql 
mysqlbinlog relay-bin.000010 > /root/RelayQueries.txt 
less /root/RelayQueries.txt 
0

如果你有多個模式考慮使用多線程從屬複製。這是一個相對較新的功能。

這可以動態完成,而無需停止server.Just停止從屬SQL線程。

STOP SLAVE SQL_THREAD; 
SET GLOBAL slave_parallel_threads = 4; 
START SLAVE SQL_THREAD;