主备不一致:Table definition on master and slave does not match

  • 时间:
  • 浏览:1
  • 来源:uu直播快3_UU快3直播平台

TABLE_CATALOG: NULL

+—————-+———————+——+—–+——————-+—————————–+

EXTRA:

Last_SQL_Error: Table definition on master and slave does not match: Column 10 type mismatch – received type 3, dbname.table_name has type 8

Master_SSL_CA_File:

CHARACTER_MAXIMUM_LENGTH: NULL

Last_IO_Error:

COLUMN_NAME: ScanTaskID

昨天一块儿事在线上做变更,为了保证主库的稳定性,先在备库把binlog关闭,有如果 在进行DDL变更,在通过切换HA,把备库切换为主库,在老的主库上做DDL变更

| ScanTaskID | int(11) | YES | | NULL | |

NUMERIC_SCALE: 0

TABLE_NAME: table_name

COLUMN_NAME: ScanTaskID

COLUMN_DEFAULT: NULL

root@127.0.0.1 : information_schema 14:59:19> select * from information_schema.columns where table_schema=”dbname” and table_name=”table_name” and ORDINAL_POSITION= 10\G;

COLUMN_TYPE: int(11)

mysql -uroot dbname -e “show create table table_name”>slave.sql

+—————-+———————+——+—–+——————-+—————————–+

<4>刚才看过从 information_schema.columns 中查询有大大问题的列的如果,直接代入ORDINAL_POSITION= 10得到的是ScanTaskID

master:

TABLE_NAME: table_name

CHARACTER_MAXIMUM_LENGTH: NULL

1 row in set (0.00 sec)

*************************** 1. row ***************************

CHARACTER_OCTET_LENGTH: NULL

| AddTime | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |

Master_SSL_Allowed: No

master:

CHARACTER_SET_NAME: NULL

| DomainName | varchar(255) | NO | MUL | NULL | |

*************************** 1. row ***************************

NUMERIC_SCALE: 0

1 row in set (0.00 sec)

Exec_Master_Log_Pos: 1046252634

| Field | Type | Null | Key | Default | Extra |

NUMERIC_PRECISION: 10

COLUMN_COMMENT:

<3>查看同事昨天的DDL变更脚本,涉及到加字段,调整字段的长度,看上去很平常,

root@127.0.0.1 : dbname 17:46:35> desc table_name;

DATA_TYPE: int

问了一下B2B的plinux,我门歌词 都 这样加字段的如果,才里装去去备库上去做,你是什么 的还是在主库上直接做的;

COLUMN_DEFAULT: NULL

Skip_Counter: 0

<5>5.5中报错显得更加人性了:

查看数据字段,主备库还是一致的,你是什么 如果好像到了穷途;

| urlhash | varchar(32) | YES | UNI | | |

COLLATION_NAME: NULL

| duplicateHash | varchar(32) | YES | | | |

Until_Condition: None

slave:

slave:

| Description | varchar(255) | YES | | NULL | |

ORDINAL_POSITION: 10

Column 0 of table ‘test.t3’ cannot be converted from type ‘int’ to type ‘bigint(20)’;

<2>查看出大大问题的数据字段:

COLUMN_COMMENT:

NUMERIC_PRECISION: 10

root@127.0.0.1 : information_schema 14:59:40> select * from columns where table_schema=”dbname” and table_name=”table_name” and ORDINAL_POSITION= 10\G;

Last_IO_Errno: 0

COLLATION_NAME: NULL

ORDINAL_POSITION: 10

COLUMN_TYPE: int(11)

| SubTaskID | bigint(20) unsigned | NO | PRI | NULL | auto_increment |

字段,但出大大问题的字段是第11为字段(即我门歌词 都 调整长度的字段),不多binlog中是从0始于 计算字段的位置的;

COLUMN_KEY:

看上去不多做法这样不多的大大问题,有如果 当备库变更一做完,HA切换到备库,始于 老主库变更的如果,备库就出现克隆技术出现错误:

Last_SQL_Errno: 1535

| TaskTag2 | varchar(255) | YES | | NULL | |

| ServerBanner | varchar(255) | YES | | NULL | |

TABLE_SCHEMA: dbname

Master_SSL_Verify_Server_Cert: No

Seconds_Behind_Master: NULL

+—————-+———————+——+—–+——————-+—————————–+

Until_Log_File:

mysql -uroot dbname -e “show create table table_name”>master.sql

COLUMN_KEY:

PRIVILEGES: select,insert,update,references

1 row in set (0.00 sec)

TABLE_SCHEMA: dbname

<6>.那怎么才能 才能 处置不多的大大问题喃,可能我门歌词 都 的库采用的是row模式,有如果把slave的克隆技术改为statement就不能了,将主库的binlog_format由row改为statement,不多达到备库的binlog就不不在 现错误;

<1>从你是什么 错误上来看,是主备的表价值形式不一致愿因 的,有如果 如果的克隆技术都不 好好的,为哪此做完变更后就会出现你是什么 大大问题,应该是在DDL变更后愿因 的大大问题;

Last_Error: Table definition on master and slave does not match: Column 10 type mismatch – received type 3, dbname.table_name has type 8

Master_SSL_Cert:

Until_Log_Pos: 0

| R_DomainName | varchar(255) | YES | MUL | NULL | |

| ip | varchar(45) | YES | | NULL | |

PRIVILEGES: select,insert,update,references

TABLE_CATALOG: NULL

IS_NULLABLE: YES

| crc_DomainName | int(10) unsigned | YES | MUL | NULL | |

我门歌词 都 是先在备库做的变更,有如果 在到主库的变更,期间的binlog是关闭的,这如果,印风同学想到可能在备库变更的如果,主库的业务是这样停止的,

| wapscore | int(11) | YES | | 0 | |

| webappid | int(11) | YES | | NULL | |

DATA_TYPE: int

Master_SSL_Key:

CHARACTER_OCTET_LENGTH: NULL

| enable | tinyint(1) | YES | | 0 | |

EXTRA:

| HttpStatus | int(11) | YES | | NULL | |

| url | varchar(333) | NO | UNI | NULL | |

可能主库变更的数据同步到备库,备库的变更做完,主备可能不一致了,不多话语,就会造成克隆技术失败了,看过看脚本涵盖字段长度调长的,这下就迎刃而解了;

Master_SSL_Cipher:

CHARACTER_SET_NAME: NULL

IS_NULLABLE: YES

diff -u master.sql slave.sql这样找到一十个 多表价值形式有哪此大大问题图片;

Relay_Log_Space: 2910773181

Master_SSL_CA_Path:

| TaskTag | varchar(255) | NO | MUL | NULL | |