基于MySQL主从数据不一致
- MySQL5.6 binlog statment格式 主从架构,table的字符集是utf8mb4 插入表情符号的时候,slave无法识别,显示乱码
- 猜想可能是因为binlog字符集默认是utf8格式的。写入binlog的时候就已经乱码
- table的字符集是utf8,并且设置某个字段的字符集类型是utf8mb4。在这个字段插入表情,并且进行pt2.2.19 主从数据同步的时候生成的DML语句也无法识别表情包显示乱码。
实验结果
- 猜想1不成立,因为binlog的写入都是二进制。从库出现字段先睡表情是乱码的现象猜测可能是因为在做逻辑备份的时候mysqldump默认的字符集是utf8导致的。
- mysqldump备份的时候默认的是utf8字符集,导致在备份字符集是utf8mb4的table里面有些数据是表情包的字段显示乱码。在导入数据进入的时候还是乱码。
- 猜想2成立。
- table的字符集是utf8
- table的某个column字符集是utfbmb4
- table中字符集是utf8mb4的字段有存在表情包
- 主从复制中这个slave的table的中字段表情包是乱码
- 在进行正常的主从同步的时候(即正常的通过binlog传输和回放)不会出现slave的表情包显示是乱码现象
- 在pt-table-sync主从数据同步的时候生成的SQL显示的还是表情包乱码现象。
pt-table-sync --print --charset=utf8 --sync-to-master h=slave_host,u=username,p=‘password‘,P=3306 --databases=schema_name --tables=tables_1,tables_2
- 在使用pt-table-sync的时候直接使用execute这个参数的时候,假如slave不能同步master,则会修改master的数据使得master同步slave的数据。
pt-table-sync --print --charset=utf8 --execute --sync-to-master h=slave_host,u=username,p=‘password‘,P=3306 --databases=schema_name --tables=tables_1,tables_2
原文地址:http://blog.51cto.com/11819159/2108253
时间: 2024-11-08 02:49:14