如果你遵從了上述說明，復制設置仍然不工作，首先檢查下面各項：
· 檢查錯誤日志的消息。許多用戶遇到問題后沒有及時地這樣做而浪費了時間。
· 主服務器記錄到了二進制日志？用SHOW MASTER STATUS檢查。如果已經記錄，Position應為非零。如果沒有記錄，確認正用log-bin和server-id選項運行主服務器。
· 是否從服務器在運行？使用SHOWSHOW SLAVE STATUS檢查是否slave_IO_Running和slave_SQL_Running的值均為Yes。如果不是，驗證當啟動從服務器時使用的選項。
· 如果從服務器正在運行，建立了與主服務器的連接嗎？使用SHOW PROCESSLIST，找出I/O和SQL線程并檢查它們的State列看它們如何顯示。參見6.3節，“復制實施細節”。如果I/O線程狀態為Connecting to master，驗證主服務器上復制用戶的權限、主服務器主機名、DNS設置，是否主服務器真正在運行，以及是否可以從從屬服務器訪問。
· 如果從服務器以前在運行但是現在已經停止，原因通常是在主服務器上成功的部分語句在從服務器上失敗了。如果你正確快照了主服務器，并且從來沒有不通過服務器線程修改從服務器上的數據，這種現象不應發生。如果發生，應為一個bug或你遇到了一個6.7節，“復制特性和已知問題” 描述的已知的復制限制。如果是一個bug，參見6.11節，“通報復制缺陷”查閱如何通報的說明。
· 如果某個在主服務器上成功的語句拒絕在從服務器上運行，并且不能執行完全的數據庫重新同步(即刪除從服務器的數據庫并從主服務器復制新的快照)，嘗試：
1. 確定是否從服務器的表與主服務器的不同。盡力了解發生的原因。然后讓從服務器的表與主服務器的一樣并運行START SLAVE。
2. 如果前面的步驟不工作或不適合，盡力了解手動更新是否安全(如果需要)，然后忽視來自主服務器的下一個語句。
3. 如果你確定可以跳過來自主服務器的下一個語句，執行下面的語句：
4. mysql> SET GLOBAL SQL_slave_SKIP_COUNTER = n；
5. mysql> START SLAVE；
如果來自主服務器的下一個語句不使用AUTO_INCREMENT或LAST_INSERT_ID()，n 值應為1。否則，值應為2。使用AUTO_INCREMENT或LAST_INSERT_ID()的語句使用值2的原因是它們從主服務器的二進制日志中取兩個事件。
6. 如果你確保從服務器啟動時完好地與主服務器同步，并且沒有更新從服務器線程之外的表，則大概詫異是由于bug。如果你正運行最近的版本，請通報該問題。如果你正運行舊版本MySQL，盡力升級到最新的產品版本。