MySQL从库的列类型不一致导致的复制异常问题
官方文檔：https://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html
slave_type_conversions??這個(gè)參數(shù)在mysql5.5.3?引入，目的是啟用row?格式的bin-log?的時(shí)候，如果主從的column?的數(shù)據(jù)類型不一致，會(huì)導(dǎo)致復(fù)制失敗，mysql5.5.3?之后支持，主庫是int?從庫是bigint?這種類型的復(fù)制，
這個(gè)參數(shù)的意義就是控制些類型轉(zhuǎn)換容錯(cuò)性。
?
如果從庫的字段類型范圍比主庫類型大，那么設(shè)置slave_type_conversions=ALL_NON_LOSSY后復(fù)制沒有問題的。
如果從庫類型比主庫類型小，比如從int?復(fù)制到tinyint?，雖然可以通過設(shè)置slave_type_conversions=ALL_LOSSY,ALL_NON_LOSSY讓主從不出問題，但是實(shí)際上會(huì)造成數(shù)據(jù)丟失的風(fēng)險(xiǎn)。
?
幾種值的設(shè)置：
??? ALL_LOSSY：允許數(shù)據(jù)截?cái)?/span>
??? ALL_NON_LOSSY：不允許數(shù)據(jù)截?cái)?#xff0c;如果從庫類型大于主庫類型，是可以復(fù)制的，反過了，就不行了，從庫報(bào)復(fù)制錯(cuò)誤，復(fù)制終止。
??? ALL_LOSSY,ALL_NON_LOSSY:?所有允許的轉(zhuǎn)換都會(huì)執(zhí)行，而不管是不是數(shù)據(jù)丟失。
????空值（不設(shè)置）：要求主從庫的數(shù)據(jù)類型必須嚴(yán)格一致，否則都報(bào)錯(cuò)。
| Mode | Effect |
| ALL_LOSSY | In this mode, type conversions that would mean loss of information are ?permitted. This does not ?imply that non-lossy conversions are permitted, merely that only cases ?requiring either lossy conversions or no conversion at all are permitted; for ?example, enabling?only?this mode permits an?INT?column to be converted to?TINYINT?(a lossy conversion), but not a?TINYINT?column to an?INT?column (non-lossy). Attempting ?the latter conversion in this case would cause replication to stop with an ?error on the slave. |
| ALL_NON_LOSSY | This mode permits conversions that do not require truncation or other ?special handling of the source value; that is, it permits conversions where ?the target type has a wider range than the source type.?【確保從庫的列類型更寬泛些也不會(huì)導(dǎo)致復(fù)制報(bào)錯(cuò)】 Setting this ?mode has no bearing on whether lossy conversions are permitted; this is ?controlled with the?ALL_LOSSY?mode. If ?only?ALL_NON_LOSSY?is set, ?but not?ALL_LOSSY, then ?attempting a conversion that would result in the loss of data (such as?INT?to?TINYINT, or?CHAR(25)?to?VARCHAR(20)) causes the slave to stop with an ?error. |
| ALL_LOSSY,ALL_NON_LOSSY | When this mode is set, all supported type conversions are permitted, whether ?or not they are lossy conversions. |
| ALL_SIGNED | Treat promoted integer types as signed values (the default behavior). |
| ALL_UNSIGNED | Treat promoted integer types as unsigned values. |
| ALL_SIGNED,ALL_UNSIGNED | Treat promoted integer types as signed if possible, otherwise as ?unsigned. |
| [empty] | When?slave_type_conversions?is not ?set, no attribute promotion or demotion is permitted; this means that all ?columns in the source and target tables must be of the same types. This mode is the default. |
生產(chǎn)環(huán)境一個(gè)案例：
從庫是有個(gè)oracle系統(tǒng)去查數(shù)據(jù)的，原先從庫的cp_shop_activity表示utf8mb4字符集，oracle不支持。因此在這個(gè)從庫上手動(dòng)修改了mode字段的字符類型為varchar(200) utf8，修改后的字段類型如下圖：
但是沒幾天后，發(fā)現(xiàn)主從復(fù)制報(bào)錯(cuò)了，錯(cuò)誤碼1677。從庫上記錄的錯(cuò)誤日志如下：
我們看下主庫的mode字段是varchar(50)，從庫的mode字段是varchar(200)。
在從庫設(shè)置：
stop slave;
set global slave_type_conversions=ALL_NON_LOSSY;??
#?默認(rèn)slave_type_conversions為空，表示強(qiáng)制從庫和主庫的字段類型一致，不然就停止復(fù)制。設(shè)置為ALL_NON_LOSSY就稍微寬泛些同時(shí)確保不會(huì)造成類型轉(zhuǎn)換的問題。
start slave;
show slave status\G ?
這樣即可解決這個(gè)問題。
?
本文轉(zhuǎn)自 lirulei90 51CTO博客，原文鏈接：http://blog.51cto.com/lee90/1913061，如需轉(zhuǎn)載請自行聯(lián)系原作者
總結(jié)
以上是生活随笔為你收集整理的MySQL从库的列类型不一致导致的复制异常问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： yield next和yield* ne
- 下一篇： Centos 6.4下MySQL安装及配