MySQL从库的列类型不一致导致的复制异常问题
官方文檔：https://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html
slave_type_conversions??這個參數在mysql5.5.3?引入，目的是啟用row?格式的bin-log?的時候，如果主從的column?的數據類型不一致，會導致復制失敗，mysql5.5.3?之后支持，主庫是int?從庫是bigint?這種類型的復制，
這個參數的意義就是控制些類型轉換容錯性。
?
如果從庫的字段類型范圍比主庫類型大，那么設置slave_type_conversions=ALL_NON_LOSSY后復制沒有問題的。
如果從庫類型比主庫類型小，比如從int?復制到tinyint?，雖然可以通過設置slave_type_conversions=ALL_LOSSY,ALL_NON_LOSSY讓主從不出問題，但是實際上會造成數據丟失的風險。
?
幾種值的設置：
??? ALL_LOSSY：允許數據截斷
??? ALL_NON_LOSSY：不允許數據截斷，如果從庫類型大于主庫類型，是可以復制的，反過了，就不行了，從庫報復制錯誤，復制終止。
??? ALL_LOSSY,ALL_NON_LOSSY:?所有允許的轉換都會執行，而不管是不是數據丟失。
????空值（不設置）：要求主從庫的數據類型必須嚴格一致，否則都報錯。
| 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.?【確保從庫的列類型更寬泛些也不會導致復制報錯】 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. |
生產環境一個案例：
從庫是有個oracle系統去查數據的，原先從庫的cp_shop_activity表示utf8mb4字符集，oracle不支持。因此在這個從庫上手動修改了mode字段的字符類型為varchar(200) utf8，修改后的字段類型如下圖：
但是沒幾天后，發現主從復制報錯了，錯誤碼1677。從庫上記錄的錯誤日志如下：
我們看下主庫的mode字段是varchar(50)，從庫的mode字段是varchar(200)。
在從庫設置：
stop slave;
set global slave_type_conversions=ALL_NON_LOSSY;??
#?默認slave_type_conversions為空，表示強制從庫和主庫的字段類型一致，不然就停止復制。設置為ALL_NON_LOSSY就稍微寬泛些同時確保不會造成類型轉換的問題。
start slave;
show slave status\G ?
這樣即可解決這個問題。
?
本文轉自 lirulei90 51CTO博客，原文鏈接：http://blog.51cto.com/lee90/1913061，如需轉載請自行聯系原作者
總結
以上是生活随笔為你收集整理的MySQL从库的列类型不一致导致的复制异常问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： yield next和yield* ne
- 下一篇： Centos 6.4下MySQL安装及配