如何分析skip-slave-start的重要性

如何分析skip-slave-start的重要性，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

一次問題解決過程

原來做復(fù)制的主機(jī)因?yàn)閿?shù)據(jù)丟失需要重新創(chuàng)建復(fù)制環(huán)境，機(jī)器上已經(jīng)有了主庫數(shù)天前的備份，于是刪除數(shù)據(jù)目錄直接把備份放上去，結(jié)果發(fā)現(xiàn)復(fù)制沒有抱錯(cuò)，show slave status一切正常，select count(*)某張大表也是不斷增加，但是查詢?cè)摫淼膍ax id確遲遲不動(dòng)。

于是把這條最大的數(shù)據(jù)拿出來看，發(fā)現(xiàn)數(shù)據(jù)是今天的。而slave的同步信息顯示才讀取到2天前的binlog而已。

這臺(tái)機(jī)器既做slave又做master，設(shè)置了

log-bin
log-slave-updates

環(huán)境比較復(fù)雜，一開始猜想是不是環(huán)境設(shè)置問題造成的，但是檢查回來沒啥問題，再仔細(xì)想想。猜到問題原因，問了下，果然是沒有刪除master.info造成的，因?yàn)槟J(rèn)Mysql的slave會(huì)隨數(shù)據(jù)庫啟動(dòng)而啟動(dòng)，因此mysql就直接從當(dāng)前位置開始讀取，造成讀取了幾條今天的數(shù)據(jù)，而后因?yàn)閏hange master把復(fù)制的信息重置了，因此光從max id看就是沒有變化而數(shù)據(jù)卻在實(shí)際增加，等到了這幾條數(shù)據(jù)就會(huì)報(bào)1062違反重復(fù)的錯(cuò)誤。所以為了安全期間，復(fù)制環(huán)境的數(shù)據(jù)庫還是設(shè)置--skip-slave-start參數(shù)，防止復(fù)制隨著mysql啟動(dòng)而自動(dòng)啟動(dòng)。

看完上述內(nèi)容，你們掌握如何分析skip-slave-start的重要性的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！