写在最前

1356的错误，在前几天写的mysqldump问题集合里面已经写过了，然而本次按照常规的套路无法处理这次的1356错误，所以单独写出来

1356以及相关mysqldump错误参阅这个问题集合：mysqldump问题处理集合

---

IP架构

问题数据库：172.17.100.106

参考库：172.17.100.107、172.17.100.100

106库是一个多次实验之后，做过主库也做过从库的数据库；107库是一个刚刚初始化的新库；

问题描述

执行全库的mysqldump时导出报了一个1356的权限错误

问题排查

根据前面处理1356的经验，对mysql.proc和information_schema.views进行查询，然而并没有发现任何异常！

特别是下图（语句②的执行结果图）红框中的host_summary这个在上图中出现的报错视图，type和definer可以说都是再正常不过了。

①SELECT definer,type FROM mysql.proc GROUP BY definer,type;

②select TABLE_SCHEMA,table_name,definer,SECURITY_TYPE from information_schema.views;

对比参考数据库，发现106库（问题库）的第①个语句结果略微有一些不一样，下图是107库（参考库）的执行结果

而在106库的结果中，只有第一行

对106库和107库分别执行mysql.proc的全库查询发现：107库有48行数据，而106库只有6行数据；再参考100库，数据量也远远不止6条！

决定先对106库的mysql.proc表进行数据补全

处理问题

思路是先对106库的mysql.proc表进行备份，再将107库的mysql.proc表数据导过来

create table qimo.proc select * from mysql.proc;

报错：ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.

#需要关闭GTID，此处采用在线关闭

set global gtid_mode='ON_PERMISSIVE';

set global gtid_mode='OFF_PERMISSIVE';

set global gtid_mode='OFF';

set global ENFORCE_GTID_CONSISTENCY='OFF'

#再次执行

create table qimo.proc select * from mysql.proc;

报错：ERROR 1067 (42000): Invalid default value for 'modified'

典型的sql_mode错误，查询mysql.proc表可以发现modified又冲突了，改sql_mode去

这里还不能带global，如果是set global sql_mode的话，不会在这个会话里生效

set sql_mode='STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

#解决这2个错误后，表的复制完成了

#关闭GTID，并将107库的mysql.proc表进行复制

create database qimo;

create table qimo.pr select * from mysql.proc;

#将107库的qimo.proc表导出（仅导出结构-d，数据结构都导出则不加-d）

mysqldump -uroot -p密码 qimo proc > qimo.sql

#将sql拷贝到106库，执行单表的导入（导出的单表里面有数据和结构，但是不会写表的归属数据库，所以在执行单表导入的时候，需要写明库名，比如下面的粗斜体qimo）

mysql -uroot -p密码 qimo < qimo.sql

将106库的2张表合并

use qimo;

insert into proc select * from pr;

#将106库的qimo.proc表导出

mysqldump -uroot -p密码 qimo proc > proc.sql

#查询mysql.proc表的建表语句

use mysql;

show create table proc;

#将建表语句复制下来，编辑之前导出的proc.sql

#将建表语句进行替换（mysql.proc是系统表，他的建表语句和通过create table复制出去的qimo.proc是不同的）

#导入mysql.proc表

mysql -uroot -p密码 mysql < proc.sql

为什么不直接insert数据到mysql.proc表呢？

系统表是不能加写锁的，我也尝试了直接insert，然后就得到了下面的报错

insert into mysql.proc select * from qimo.proc;

ERROR 1428 (HY000): You can't combine write-locking of system tables with other tables or lock types

验证

sys库下面所有的view已经可以正常读取

执行106库的全库导出也顺利完成

---

后话

测试库只求解决问题，干起来倒是肆无忌惮，老实说我也不知道正式库到底能不能在生产时间这么直接去干掉mysql.proc再重建