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安装及配