MySQL主從復(fù)制錯(cuò)誤如何解決，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

發(fā)展壯大離不開廣大客戶長期以來的信賴與支持，我們將始終秉承“誠信為本、服務(wù)至上”的服務(wù)理念，堅(jiān)持“二合一”的優(yōu)良服務(wù)模式，真誠服務(wù)每家企業(yè)，認(rèn)真做好每個(gè)細(xì)節(jié)，不斷完善自我，成就企業(yè)，實(shí)現(xiàn)共贏。行業(yè)涉及食品包裝袋等，在成都網(wǎng)站建設(shè)、全網(wǎng)整合營銷推廣、WAP手機(jī)網(wǎng)站、VI設(shè)計(jì)、軟件開發(fā)等項(xiàng)目上具有豐富的設(shè)計(jì)經(jīng)驗(yàn)。

| 背景

有客戶咨詢說，自己的從庫show slave status出現(xiàn)了報(bào)錯(cuò)，報(bào)錯(cuò)信息顯示如下：

column 4 of table 'hh_db_mk.hh_vhl_application'cannot be converted from type 'datetime' to type 'varchar(20)'

  截圖顯示如下：

得到的信息如下：

• 從庫停了兩天，重啟之后新建了這個(gè)表，然后就報(bào)了這個(gè)錯(cuò)。

| 思路

看到這個(gè)報(bào)錯(cuò)，首先想到的是兩邊表結(jié)構(gòu)是否不一致。查看后發(fā)現(xiàn)，表結(jié)構(gòu)一模一樣。

疑問客戶是否有對表結(jié)構(gòu)做了更改，導(dǎo)致了這個(gè)報(bào)錯(cuò)。但詢問客戶后，客戶表示沒有做任何表結(jié)構(gòu)的更改。但同時(shí)向客戶提出，解析下binlog看一下報(bào)錯(cuò)位置的sql語句。當(dāng)然這個(gè)過程花了些時(shí)間。

出現(xiàn)列轉(zhuǎn)換錯(cuò)誤，一般都是由于主從之間字符集不一致導(dǎo)致的。于是詢問客戶，主從庫之間的sql_mode和字符集是否不一致，結(jié)果顯示均一致。表結(jié)構(gòu)也一致。 

這個(gè)時(shí)候，沒啥思路了。但還是要求客戶解析下binlog看一下對應(yīng)的sql語句，執(zhí)行mysqlbinlog -vvv mysql-bin.001744 --start-position=50585341 | head -100。不過，發(fā)現(xiàn)對應(yīng)的binlog已經(jīng)被purge掉了，然后在從庫上解析對應(yīng)的relay-log，執(zhí)行mysqlbinlog -vvv mysql-relay.000003 --start-position=50585511 --base64=decode-rows | head -100，如下：

可以看到，relay-log里面出錯(cuò)點(diǎn)對應(yīng)的insert語句和目前的表結(jié)構(gòu)確實(shí)不一樣。報(bào)錯(cuò)信息顯示的是column 4 cannot be converted from type 'datetime' to type 'varchar(20)'，我們知道MySQL中的column是從0開始計(jì)數(shù)的，所以在relay-log里column 4對應(yīng)的是第五個(gè)字段add_time datetime，在從庫表里對應(yīng)的是第五個(gè)字段system_source varchar(20)，導(dǎo)致出現(xiàn)了這個(gè)報(bào)錯(cuò)。

| 解決

表結(jié)構(gòu)已經(jīng)發(fā)生了變更，讓客戶重新從主庫上拉一份數(shù)據(jù)到從庫，做恢復(fù)。

| 總結(jié)

其實(shí)這是一個(gè)比較簡單的問題，但提醒我們，客戶的某些確定性的操作不能都信以為真，也有可能客戶自己也不知道，或者自己做了什么操作但是卻忘記了，以為沒有做過。

我們要做的，還是要找出真實(shí)的情況，以實(shí)際為準(zhǔn)，不必太糾結(jié)于客戶的說法。客戶的說法不一定正確，不能因此而被誤導(dǎo)。

Executed_Gtid_Set記錄的是已經(jīng)執(zhí)行過的gtid，這里show slave status記錄的最后執(zhí)行的一個(gè)事務(wù)是8c268782-517e-11e7-ab9a-005056834ee0:69415237，出錯(cuò)的是下一個(gè)8c268782-517e-11e7-ab9a-005056834ee0:69415238。show slave status顯示的Relay_Log_File:mysql-relay.000003、Relay_Log_Pos:50585511，則記錄的是出錯(cuò)的那個(gè)事務(wù)的位置點(diǎn)。

看完上述內(nèi)容，你們掌握MySQL主從復(fù)制錯(cuò)誤如何解決的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝各位的閱讀！

本文名稱：MySQL主從復(fù)制錯(cuò)誤如何解決-創(chuàng)新互聯(lián)
分享鏈接：http://www.ekvhdxd.cn/article30/ejdso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、企業(yè)網(wǎng)站制作、軟件開發(fā)、小程序開發(fā)、網(wǎng)站導(dǎo)航、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)