溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如何分析skip-slave-start的重要性，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
一次問題解決過程
原來做復制的主機因為數據丟失需要重新創建復制環境，機器上已經有了主庫數天前的備份，于是刪除數據目錄直接把備份放上去，結果發現復制沒有抱錯，show slave status一切正常，select count(*)某張大表也是不斷增加，但是查詢該表的max id確遲遲不動。
于是把這條最大的數據拿出來看，發現數據是今天的。而slave的同步信息顯示才讀取到2天前的binlog而已。
這臺機器既做slave又做master，設置了
log-bin
log-slave-updates
環境比較復雜，一開始猜想是不是環境設置問題造成的，但是檢查回來沒啥問題，再仔細想想。猜到問題原因，問了下，果然是沒有刪除master.info造成的，因為默認Mysql的slave會隨數據庫啟動而啟動，因此mysql就直接從當前位置開始讀取，造成讀取了幾條今天的數據，而后因為change master把復制的信息重置了，因此光從max id看就是沒有變化而數據卻在實際增加，等到了這幾條數據就會報1062違反重復的錯誤。所以為了安全期間，復制環境的數據庫還是設置--skip-slave-start參數，防止復制隨著mysql啟動而自動啟動。
看完上述內容，你們掌握如何分析skip-slave-start的重要性的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
