MySQL從站I/O線程未運行

Question

我已經爲MySQL服務器設置了複製。我可以使用複製用戶/密碼從從機連接到主服務器。我運行了從屬SQL線程，但從屬線程未運行，並且使用'顯示從屬狀態'進行檢查時，從屬I/O狀態爲空。可能是什麼問題呢？

我該如何解決這個問題？重新啓動奴隸並沒有幫助。

這是我的不好：我沒有給*.*賦予'複製奴隸'特權，而只是給my_db.*。

Answer 1

，而不是給人一種「複製 奴」特權，我才 給它MY_DB。*。

複製從屬只是一個全局權限（即，每個用戶只），這意味着，一個命令如

GRANT REPLICATION SLAVE on mydb.* TO 'someuser'@'%'; 

沒有任何影響，你不能授予它每個數據庫/列/表。

你需要運行的命令是：

GRANT REPLICATION SLAVE on *.* TO 'someuser'@'%'; 

然後做一個START SLAVE。你也許會發現查看mysql錯誤日誌很有用。

我建議你仔細閱讀replication setup documentation，因爲它詳細解釋了所有這些。

Answer 2

我也遇到同樣的問題，我嘗試這個步驟

首先在my.cnf中添加以下地方的[mysqld]這個代碼或my.ini的slave-skip-errors=1046 這將跳過所有重複的項目，因爲我們將執行全二進制日誌文件複製停止位置，您可以在成功複製後註釋此代碼。

1.STOP SLAVE;

2.RESET SLAVE;

3.CHANGE MASTER TO MASTER_LOG_FILE ='mysql-bin.000049';

Note: MASTER_LOG_FILE must be the last file where it stop from replicating 

4.CHANGE MASTER TO MASTER_LOG_POS = 98;

5.START SLAVE;

檢查，如果你是成功的

Answer 3

我面臨同樣的問題，使用以下步驟修復。完成的主題鏈接是http://www.percona.com/forums/questions-discussions/percona-xtrabackup/11842-backup-stopped-working-slave-sql-running-no

步驟與@ Luxknight007提到的相同，除了他的第2步。然而，此線程包含更多的細節，這是非常有用的。以下是我使用的解決方案，它工作。

「第一個問題是你改變了複製的位置不是固定的錯誤，並使用了不正確的二進制日誌文件名格式（你可能只是用來從你掛我猜後的一個）。爲了回到你開始的位置，你需要找到binlog文件並確定slave sql_thread停在哪裏。根據您的從站狀態輸出，它看起來像從站正在從新的binlog文件中讀取（您可以看到Read_Master_Log_Pos的值小於Exec_Master_Log_Pos的值，這意味着它必須讀取比slave sql_thread更新的binlog文件停在），所以你需要找到slave sql_thread實際上失敗的binlog文件。所以，看在錯誤日誌中類似下面：

代碼：

2013-10-08 12:48:51 37545 [ERROR] Slave SQL: Error 'Table 'testdb.test2' doesn't exist' on query. Default database: 'testdb'. Query: 'insert into test1 select * from test2', Error_code: 1146 
2013-10-08 12:48:51 37545 [Warning] Slave: Table 'testdb.test2' doesn't exist Error_code: 1146 
2013-10-08 12:48:51 37545 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 3427 

這是我重新創建了一個樣本，所以你會有點不同。請注意，ERROR與您在奴隸狀態中看到的相似。因此，在錯誤日誌文件中找到特定的錯誤消息，然後找到文件名和位置（在我的示例中，我們停在日誌'mysql-bin.000001'位置3427'）的結尾部分。根據你的show slave狀態，位置應該是315098143，因爲它是從屬sql_thread停止執行事件（Exec_Master_Log_Pos），但是io_thread不斷讀取新事件（Read_Master_Log_Pos）。

一旦找到正確的binlog文件名稱和位置，請使用錯誤日誌中的信息在您的slave上重新運行change master語句。請注意，你的文件名應該像「newcrmdb1-bin.XXXXXX」，而不是mysql-bin.XXXXXX（你可以在上面看到你的show slave狀態這個命名約定）。

代碼：

mysql> change master to MASTER_LOG_FILE='newcrmdb1-bin.XXXXXX', Master_Log_Pos=315098143; 

change master to MASTER_LOG_FILE='mysql-bin.000082' , Master_Log_Pos=47914844; 

一旦你指出回到那裏從SQL_THREAD失敗的初始複製位置，你需要再修復它抱怨與啓動錯誤。

初始複製錯誤似乎告訴你表asteriskcdr。 bpleadcf在從站上不存在，所以當它試圖從該表中選擇數據時，插入語句失敗。所以問題在於你的奴隸似乎已經與你的主人不同步。如果主服務器上的表是靜態的或大多是靜態的，那麼可以通過使用mysqldump從主服務器上的該表導出數據並將其加載到從服務器中來解決此問題。如果這是不可能的，或者你不關心這些數據，那麼你總是可以用sql_slave_skip_counter跳過複製語句，但是從屬設備將會進一步與主設備不同步。

如果一切都失敗了，你總是可以從主設備重建從設備作爲最後的手段。 =）「