常见报错和处理方式
常见错误处理
- 常见错误处理
- 1.ERROR 1197 :
- 2. Error code1756 & Error code1756：
- 3. ERROR 1071 (42000)
- 4. [ERROR] Semi-sync master failed on net_flush() before waiting for slave reply
- 5. [ERROR] /usr/local/mysql/bin/mysqld: The table 'test_1291870945841162' is full
- 6. [ERROR] /usr/bin/mysqld sort aborted :Error writing file /tmp/MYih9NYL(errorcode:28 No space left on device)
- null
- 7. ERROR 1118 (42000): Row size too large.
- 8. Packet for query is too large (4739923 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.
- 8.msyql导入数据时的外键约束问题
- 9.ERROR 1040 (HY000): Too many connections”
- 10.连接数原小于max_connections的设置，但是报错214
- 11. dump导出时权限不足you need (at least one of) the process privilege(s)
- 11.Error Code: 1418
1.ERROR 1197 :
错误描述
ERROR 1197 (HY000) : Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again
问题原因
执行该条sql语句其事务影响的数据量超过max_binlog_cache_size的大小，导致报错。
就像是你正在吃一个比你的嘴要大的冰淇淋，你非要一口吃进去，当然就不会成功了。解决方法是，要么一口一口吃，要么把你的嘴扩大。
主与从的max_binlog_cache_size的大小配置不相同,也会导致报这个错误。
就像是一个机械的孔，原来的孔的直径扩大了，不更换匹配的螺丝，就无法拧住。解决方法是，更换相匹配的螺丝才能拧住洞口。
mysql是采用二进制，记录日志的(binlog)。
其记录日志的过程为:数据库先把binlog写进binlog_cache中，然后再从缓存中把binlog日志写入磁盘中。
binlog_cache_size和max_binlog_cache_size就是用来控制binlog_cache大小的。
binlog_cache_size ：表示为每个session(事务)分配的内存的大小，即在事务的过程中用来存储二进制日志的缓存大小。
max_binlog_cache_size ：表示所有会话加在一起的binlog 能够使用的最大缓存大小，即在执行多语句事务时 ，所有会话的binlog使用最大内存 。(max_binlog_cache_size最小值是4096字节，最大值在32位的系统中是4G，64位的是16P)
解决方法
【1】执行sql语句报错解决方法一
通常是大事务造成的,且大事务还容易造成主从延时。建议将此事务分解为小事务执行。即将此sql语句进行拆分为多句sql，使每句sql的事务影响的数据量减小，就像将一大块冰淇淋分开吃。
强烈建议使用此方法，无需对数据库参数进行调整。
【2】执行sql语句报错解决方法二
根据实际情况，调整数据库中max_binlog_cache_size参数，最小值是4096字节，最大值在32位的系统中是4G，64位的是16P。就像是调整你的嘴的大小，以便于塞入整个冰淇淋。
设置太大，会消耗大量内存资源；设置太小，会使用临时文件。
不建议，操作不当可能导致主从出现问题。如使用此方法，从库也需要修改为相同参数，避免主从同步失败。
<1>查看全局max_binlog_cache_size的大小
show GLOBAL variables like 'max_binlog_cache_size';
<2>查看当前会话max_binlog_cache_size的大小
show session variables like 'max_binlog_cache_size';
<3>修改参数
根据实际情况修改大小，但是一定要大于你查到的参数，否则无用；如参数不够，仍需往大调。
修改当前会话的max_binlog_cache_size的大小
set session max_binlog_cache_size=500000000;
或
修改全局max_binlog_cache_size的大小
set global binlog_cache_size=500000000;
2. Error code1756 & Error code1756：
报错信息：
曲库分发 MYSQL : fenfadb68 ALERT 2020-12-22 13:34:45 5396 [Warning] Slave SQL: Worker 0 failed executing transaction cf2a7caa-c3a0-11ea-a3d9-14187745df22:1616106943 at master log mysql-bin.002151 end_log_pos 113521586; Could not execute Write_rows event on table tyqk_dispatch.tb_synctagsevt_info; Lock wait timeout exceeded; try restarting transaction Error_code: 1205; handler error HA_ERR_LOCK_WAIT_TIMEOUT; the events master log mysql-bin.002151 end_log_pos 113521586 Error_code: 1205
2020-12-22 13:34:45 5396 [ERROR] Slave SQL: ... The slave coordinator and worker threads are stopped possibly leaving data in inconsistent state. A restart should restore consistency automatically although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756
分析原因：
曲库备库有查询业务, 有时候复制要等mdl锁, 超时报错
处理方式
start slave;重启slave 即可恢复。
3. ERROR 1071 (42000)
问题现象
ERROR 1071 (42000) Specified key was too long; max key length is 767 bytes
分析原因：
其实这个“ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes”错误是指超出索引字节的限制，
并不是指字段长度限制。在官方文档“Limits on InnoDB Tables”有关于这方面的介绍、描述（详情请见参考资料）：
解决方式
在线修改
mysql> show variables like '%innodb_large_prefix%';
mysql> show variables like '%innodb_file_format%';
mysql> set global innodb_file_format = BARRACUDA;
Query OK, 0 rows affected (0.00 sec)
mysql> set global innodb_large_prefix = ON;
永久修改：
[mysqld]
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_file_per_table = ON
我们先来创建一个测试表，构造这样的错误。
mysql> use MyDB;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> CREATE TABLE `TEST` (
-> `CODE_NAME` varchar(100) NOT NULL DEFAULT '',
-> `CODE_SEQ` smallint(6) NOT NULL DEFAULT '1',
-> `ACTIVE` char(1) DEFAULT 'Y',
-> `CODE_VALUE1` varchar(250) DEFAULT NULL,
-> PRIMARY KEY (`CODE_NAME`,`CODE_SEQ`),
-> KEY `IDX_GEN_CODE` (`CODE_NAME`,`CODE_VALUE1`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE TEST MODIFY CODE_VALUE1 VARCHAR(350);
ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
mysql>
其实这个“ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes”错误是指超出索引字节的限制，
并不是指字段长度限制。在官方文档“Limits on InnoDB Tables”有关于这方面的介绍、描述（详情请见参考资料）：
MySQL 5.6文档内容如下
By default, the index key prefix length limit is 767 bytes. See Section 13.1.13, “CREATE INDEX Syntax”. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a utf8mb3 character set and the maximum of 3 bytes for each character. When the innodb_large_prefix configuration option is enabled, the index key prefix length limit is raised to 3072 bytes for InnoDB tables that use DYNAMIC or COMPRESSED row format.
Attempting to use an index key prefix length that exceeds the limit returns an error. To avoid such errors in replication configurations, avoid enablinginnodb_large_prefix on the master if it cannot also be enabled on slaves.
The limits that apply to index key prefixes also apply to full-column index keys.
MySQL 5.7文档内容如下：
If innodb_large_prefix is enabled (the default), the index key prefix limit is 3072 bytes for InnoDB tables that use DYNAMIC or COMPRESSED row format. If innodb_large_prefix is disabled, the index key prefix limit is 767 bytes for tables of any row format.
innodb_large_prefix is deprecated and will be removed in a future release. innodb_large_prefix was introduced in MySQL 5.5 to disable large index key prefixes for compatibility with earlier versions of InnoDB that do not support large index key prefixes.
The index key prefix length limit is 767 bytes for InnoDB tables that use the REDUNDANT or COMPACT row format. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a utf8mb3 character set and the maximum of 3 bytes for each character.
Attempting to use an index key prefix length that exceeds the limit returns an error. To avoid such errors in replication configurations, avoid enablinginnodb_large_prefix on the master if it cannot also be enabled on slaves.
The limits that apply to index key prefixes also apply to full-column index keys.
如果启用了系统变量innodb_large_prefix（默认启用，注意实验版本为MySQL 5.6.41,默认是关闭的，MySQL 5.7默认开启），则对于使用DYNAMIC或COMPRESSED行格式的InnoDB表，索引键前缀限制为3072字节。如果禁用innodb_large_prefix，则对于任何行格式的表，索引键前缀限制为767字节。
innodb_large_prefix将在以后的版本中删除、弃用。在MySQL 5.5中引入了innodb_large_prefix，用来禁用大型前缀索引，以便与不支持大索引键前缀的早期版本的InnoDB兼容。
对于使用REDUNDANT或COMPACT行格式的InnoDB表，索引键前缀长度限制为767字节。例如，您可能会在TEXT或VARCHAR列上使用超过255个字符的列前缀索引达到此限制，假设为utf8mb3字符集，并且每个字符最多包含3个字节。
尝试使用超出限制的索引键前缀长度会返回错误。要避免复制配置中出现此类错误，请避免在主服务器上启用enableinnodb_large_prefix（如果无法在从服务器上启用）。
适用于索引键前缀的限制也适用于全列索引键。
注意：上面是767个字节，而不是字符，具体到字符数量，这就跟字符集有关。GBK是双字节的，UTF-8是三字节的
解决方案：
1：启用系统变量innodb_large_prefix
注意：光有这个系统变量开启是不够的。必须满足下面几个条件：
1： 系统变量innodb_large_prefix为ON
2： 系统变量innodb_file_format为Barracuda
3： ROW_FORMAT为DYNAMIC或COMPRESSED
如下测试所示：
mysql> show variables like '%innodb_large_prefix%';
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| innodb_large_prefix | OFF |
+---------------------+-------+
1 row in set (0.00 sec)
mysql> set global innodb_large_prefix=on;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE TEST MODIFY CODE_VALUE1 VARCHAR(350);
ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.
mysql>
mysql> show variables like '%innodb_file_format%';
+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Barracuda |
+--------------------------+-----------+
3 rows in set (0.01 sec)
mysql> set global innodb_file_format=Barracuda;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE TEST MODIFY CODE_VALUE1 VARCHAR(350);
ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.
mysql>
mysql>
mysql> show table status from MyDB where name='TEST'\G;
*************************** 1. row ***************************
Name: TEST
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 0
Avg_row_length: 0
Data_length: 16384
Max_data_length: 0
Index_length: 16384
Data_free: 0
Auto_increment: NULL
Create_time: 2018-09-20 13:53:49
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
mysql> ALTER TABLE TEST ROW_FORMAT=DYNAMIC;
Query OK, 0 rows affected (0.05 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> show table status from MyDB where name='TEST'\G;
*************************** 1. row ***************************
Name: TEST
Engine: InnoDB
Version: 10
Row_format: Dynamic
Rows: 0
Avg_row_length: 0
Data_length: 16384
Max_data_length: 0
Index_length: 16384
Data_free: 0
Auto_increment: NULL
Create_time: 2018-09-20 14:04:05
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options: row_format=DYNAMIC
Comment:
1 row in set (0.00 sec)
ERROR:
No query specified
mysql> ALTER TABLE TEST MODIFY CODE_VALUE1 VARCHAR(350);
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0
2：使用前缀索引解决这个问题
之所以要限制索引键值的大小，是因为性能问题，而前缀索引能很好的解决这个问题。不需要修改任何系统变量。
mysql> show index from TEST;
..................................
mysql> ALTER TABLE TEST DROP INDEX IDX_GEN_CODE;
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> CREATE IDX_GEN_CODE TEST ON TEST (CODE_NAME, CODE_VALUE1(12));
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> ALTER TABLE TEST MODIFY CODE_VALUE1 VARCHAR(350);
Query OK, 1064 rows affected (0.08 sec)
Records: 1064 Duplicates: 0 Warnings: 0
问题延伸： 为什么InnoDB的索引字节数限制为767字节？ 而不是800字节呢？ 这样限制又是出于什么具体性能的考虑呢？ 暂时还没有弄清楚这些细节问题！
参考资料：
https://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html
4. [ERROR] Semi-sync master failed on net_flush() before waiting for slave reply
错误现象：
2020-10-27T16:29:51.918971+08:00 0 [ERROR] /usr/local/mysql/bin/mysqld: Got an error reading communication packets
2020-10-27T16:29:53.273176+08:00 1011139 [ERROR] Semi-sync master failed on net_flush() before waiting for slave reply
这是一个BUG，详情参考：
https://bugs.mysql.com/bug.php?id=79865
5. [ERROR] /usr/local/mysql/bin/mysqld: The table 'test_1291870945841162' is full
错误现象：
[ERROR] /usr/local/mysql/bin/mysqld: The table 'test_1291870945841162' is full
问题分析：
通过查询mysql官方站点：
http://dev.mysql.com/doc/refman/5.0/en/full-table.html 得知：
因为系统是linux，不存在操作系统和文件格式的限制，通过表的名字可以得知，该表应该是个临时表，再说数据库里面也查不到该表。
有这一句话很重要：
You are using the MEMORY (HEAP) storage engine; in this case you need to increase the
value of the max_heap_table_size system variable. See Section 5.1.3, “Server System Variables”.
解决方案：
于是就修改Mysql的配置文件/etc/my.cnf，在[mysqld]下添加/修改两行：
tmp_table_size = 256M
max_heap_table_size = 256M
tmp_table_size 并不是越高越好～
应该从语句入手，尽量减少临时表的大小，和join结果集的大小。
tmp_table_size 设置高了，假如有10个并发执行这个语句，内存马上就拥塞了。。。
系统默认是16M，别忘记重新启动mysql，你也可以在线动态修改该参数，经过这几天的观察，这个世界安静了许多。
6. [ERROR] /usr/bin/mysqld sort aborted :Error writing file /tmp/MYih9NYL(errorcode:28 No space left on device)
7. ERROR 1118 (42000): Row size too large.
错误现象：
mysql 建表时出现：
CREATE TABLE `UMLN_CATALOG_INFO_EVT2` (
`ID` decimal(10,0) NOT NULL COMMENT '编号',
`CREATE_TIME` timestamp NULL DEFAULT NULL COMMENT '创建时间',
`MODIFY_TIME` timestamp NULL DEFAULT NULL COMMENT '修改时间',
`STATE` varchar(255) DEFAULT NULL COMMENT '状态',
`RECEIVE_TIME` timestamp NULL DEFAULT NULL COMMENT '接收时间',
`PID` varchar(255) DEFAULT NULL COMMENT '门户ID',
`SEQ` varchar(255) DEFAULT NULL COMMENT '序列号',
`ACTION` varchar(255) DEFAULT NULL COMMENT '操作类型 0. 新增内容；1. 删除内容；2. 变更内容；3. 变更文件；4. 变更内容信息；5. 隐藏；6. 恢复；',
`COPYRIGHT_ID` varchar(255) DEFAULT NULL COMMENT '中音版权ID',
`SONG_ID` varchar(255) DEFAULT NULL COMMENT '统一曲库编目后的歌曲ID',
`SONG_NAME` varchar(3900) DEFAULT NULL COMMENT '统一曲库编目后的歌曲名称',
`SINGER_ID` varchar(255) DEFAULT NULL COMMENT '统一曲库编目后的歌手ID（艺术家ID）',
`SINGER_NAME` varchar(3900) DEFAULT NULL COMMENT '统一曲库编目后的歌手名字',
`LYRICS_WRITER_ID` varchar(255) DEFAULT NULL COMMENT '统一曲库编目后的词作者ID（艺术家ID）',
`LYRICS_WRITER_NAME` varchar(3900) DEFAULT NULL COMMENT '统一曲库编目后的词作者名字',
`COMPOSER_ID` varchar(255) DEFAULT NULL COMMENT '统一曲库编目后的曲作者ID（艺术家ID）',
`COMPOSER_NAME` varchar(3900) DEFAULT NULL COMMENT '统一曲库编目后的曲作者名字',
`LYRIC_URL` varchar(1024) DEFAULT NULL COMMENT 'lrc歌词文件ftp路径',
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
报错分析：
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535.
You have to change some columns to TEXT or BLOBs。
项目运行完毕后查看数据表发现有一个表没有建立，于是把建表语句拷出来，手动建表依然报错。
于是在网上搜索了好久结果发现mysql建表有个长度限制：MySQL要求一个行的定义长度不能超过65535。
（1）单个字段如果大于65535，则转换为TEXT 。
（2）单行最大限制为65535，这里不包括TEXT、BLOB。
所谓单行最大限制指的就是一张表中所有字段的所设置的长度不得超过65535字节，
例如一个表中有三个varchar字段长度30000，那么这个表的单行长度为：30000*3=90000，
大于65535则报错不能建表，这里乘以3是因为数据库用的utf8编码，3个字节表示一个字符。
解决办法：
找到原因后到回去查看entity实体代码发现这个没有建立的表中大概有一百多个字段，
而且很多string类型的字段没设置字段大小（没设置大小的情况下，默认建立varchar 255 长度），
于是乎把所有没必要设置成255长的的字段都设置小一点，改好后运行项目建表成功。
（如果你的表的中的字段长度不能改小，那就把大字段类型改成text类型，
因为单行最大限制为65535，这里不包括TEXT、BLOB。）
8. Packet for query is too large (4739923 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.
错误现象：
在导入数据的时候报如下错误：
Mysql报错：Packet for query is too large (1121604 > 1048576).You can change this value on the server by setting the max_allowed_packet variable
报错分析：
mysql5数据，插入或更新字段有大数据时（大于1M），会出现如下错误：
SEVERE: Servlet.service() for servlet [webs] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.dao.TransientDataAccessResourceException: Hibernate flushing: Could not execute JDBC batch update; SQL [update t_article set (省略部分...)author_id=? where id=?]; Packet for query is too large (1117260 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.; nested exception is java.sql.BatchUpdateException: Packet for query is too large (1117260 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.] with root cause java.sql.BatchUpdateException: Packet for query is too large (1117260 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.
mysql默认加载的数据文件不超过1M，可以通过更改mysql的配置文件my.cnf（Linux，或windows的my.ini）来更改这一默认值，从而达到插入大数据的目的。
解决办法：
MySQL的一个系统参数：max_allowed_packet，其默认值为1048576(1M)，
可以先查询一下：
show VARIABLES like '%max_allowed_packet%';
修改：
设置为2g
set global max_allowed_packet=2*1024*1024*1024;
设置为64M
set global max_allowed_packet=64*1024*1024*;
8.msyql导入数据时的外键约束问题
错误现象：
当导入数据的时候，经常会出现报告外键错误，这是由于table中有外键约束，但导入数据时数据可能还没完整，所以会出现这样的错误。
报错分析：
解决办法：
这个问题可通过FOREIGN_KEY_CHECKS解决，暂时忽略外键检查，用法如下：
set FOREIGN_KEY_CHECKS=0; #在导入前设置为不检查外键约束
set FOREIGN_KEY_CHECKS=1; #在导入后恢复检查外键约束
9.ERROR 1040 (HY000): Too many connections”
错误现象：
报错信息：
ERROR 1040 (HY000): Too many connections”
报错分析：
为了避免在连接数满的情况下无法维护数据库， 从MySQL 4.1版本开始支持的最大连接数是
max_connections+1， 除最大支持用户可以有max_connections个连接以外， 还允许有SUPER权限的账户多一个连接在数据库上进行操作。
在MySQL 8.0.14以后， 你可以设置MySQL开启独立的管理员维护端口给有SERVICE_CONNECTION_ADMIN权限的用户连接， 这个端口完全不受max_connections的限制。
解决办法：
对于mysql 5.6版本，在mysql 的root用户也无法连接数据库时，可以使用如下的命令直接修改mysql的最大连接数据：
gdb -p $(pidof mysqld) -ex "set max_connections=3000" -batch
mysql 5.7及以后的版本为了避免出现这种情况，应用的账户连接不上， 但是我们用后台的运维管理账户可以连接上。
10.连接数原小于max_connections的设置，但是报错214
错误现象：
虽然在MySQL配置文件中要求设置最大连接数为800， 但是实际上最多允许214个连
接。 检查MySQL启动日志， 可以看到MySQL限制max_connections为214的报错信息如
下：
报错分析：
解决方案1：
这个问题解决起来很简单， 应用端主动释放数据库连接（不管是客户端MySQL连接还是应用程序的连接） ， 或者在MySQL数据库上增加最大连接数如下
作为“专业”的MySQL DBA看到max_connections为214， 应该觉得很熟悉， 这明显是
操作系统进程可打开的文件句柄数限制为1024的问题， 如果要解决的话， 只需要使用
ulimit提高文件句柄数限制就可以了。 但是使用ulimit -a命令查看， 发现open files的大小限
制已经扩展到65535了。
ulimit -a
既然文件句柄数限制已经这么高了， mysqld为什么还要限制max_connections为214？
读者可以合上本书先思考一下， 还有哪些地方可以排查？
笔者确实也排查了很久， 才发现问题：
可以看到mysqld进程的最大文件句柄数限制为Max open files 1024 4096 files， 软限制
为1024， 也就说明在MySQL启动时最大文件句柄数限制还只是1024， 并不是当前使用
ulimit -a看到的65535。 询问客户才了解到， 客户比较熟悉Linux系统， 当看到报错以后，
参考网上的文档执行ulimit修改了最大文件句柄数限制， 也修改了/etc/security/limits.conf文
件， 但是由于对MySQL不熟悉， 并没有登录MySQL服务器去修改max_connections参数
值， 也没有专门重启服务器和MySQL进程， 这就导致系统上明明已经放开了进程的最大
文件句柄数为65535， 但是对于已经正常运行的mysqld进程来说， 其实最大文件句柄数仍
然是1024。 对于DBA来说， 这就类似于修改了my.cnf配置文件中的对应变量， 但是并没有
修改正在运行的MySQL的变量值， 该变量自然没有生效。
解决办法：
- MySQL在线修改最大连接数
若要修改MySQL服务器的最大连接数， 则可以登录MySQL并执行“
set global max_connections=800”命令， 设置最大连接数为800。
set global max_connections=800
然后写入配置文件。
- Linux提高进程最大文件句柄数限制
若要修改进程最大文件句柄数限制， 则可以使用ulimit命令在线修改Linux系统的最大
文件句柄数限制。 如果要使修改永久生效， 还需要修改limits.conf文件， 将ulimit命令添加
到rc.local文件中， 以便sshd能用65535这个最大文件句柄数限制启动， 并重启服务器。
ulimit命令和文件修改示例如下：
![clipboard3]()
11. dump导出时权限不足you need (at least one of) the process privilege(s)
错误现象：
报错分析：
导致该错的原因是用户的权限不足导致的
解决办法：
GRANT PROCESS ON *.* TO `cljzlog_user`@`%`;
flush privileges;
11.Error Code: 1418
错误现象：
在MySQL主从复制机器的master的数据库中创建function，报出如下错误：
Error Code: 1418. This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
报错信息：
select * from performance_schema.replication_applier_status_by_worker \G;
LAST_ERROR_NUMBER: 1418
LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'bc31aa17-e9fd-11eb-8a4d-005056ab3072:34' at master log mybinlog.000006, end_log_pos 20220; Error 'This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)' on query. Default database: ''. Query: 'CREATE DEFINER=`root`@`localhost` FUNCTION `ocs3x`.`sd_json_kvs_add`(v_json_1 json,v_json_2 json) RETURNS json
begin
declare tmp_json_keys json;
declare tmp_json_keys_length int;
declare tmp_index int;
declare tmp_key varchar(1024);
set tmp_json_keys=json_keys(v_json_2);
set tmp_json_keys_length=json_length(tmp_json_keys);
set tmp_index=0;
json_loop:loop
if tmp_index>=tmp_json_keys_length then
leave json_loop;
end if;
set tmp_key=concat('$.',json_extract(tmp_json_keys,concat('$[',tmp_index,']')));
set v_json_1=json_set(v_json_1,tmp_key,ifnull(json_extract(v_json_1,tmp_key),0)+json_extract(v_json_2,tmp_key));
set tmp_index=tmp_index+1;
end
报错分析：
原来是因为在主从复制的两台MySQL服务器中开启了二进制日志选项log-bin,slave会从master复制数据，而一些操作，比如function所得的结果在master和slave上可能不同，所以存在潜在的安全隐患。因此，在默认情况下会阻止function的创建。
解决办法：
有两种办法来解决这一问题。
方法一：
将log_bin_trust_function_creators参数设置为ON，这样以来开启了log-bin的MySQL Server便可以随意创建function。这里存在潜在的数据安全问题，除非明确的知道创建的function在master和slave上的行为完全一致。
设置该参数可以用动态的方式或者指定该参数来启动数据库服务器或者修改配置文件后重启服务器。需注意的是，动态设置的方式会在服务器重启后失效，命令如下：
主从都修改如下参数配置：
mysql> show variables like 'log_bin_trust_function_creators';
mysql> set global log_bin_trust_function_creators=1;
修改至配置文件：
另外，如果是在master上创建函数，想通过主从复制的方式将函数复制到slave上则也需在开启了log-bin的slave中设置上述变量的值为ON（变量的设置不会从master复制到slave上，这点需要注意），否则主从复制会报错。
方法二：
明确指明函数的类型。
1 DETERMINISTIC 不确定的
2 NO SQL 没有SQl语句，当然也不会修改数据
3 READS SQL DATA 只是读取数据，当然也不会修改数据
比如：CREATE DEFINER=`username`@`%` READS SQL DATA FUNCTION `fn_getitemclock`(i_itemid bigint,i_clock int,i_pos int) RETURNS int(11)...
如此相当于明确的告知MySQL服务器这个函数不会修改数据，因此可以在开启了log-bin的服务器上安全的创建并被复制到开启了log-bin的slave上。
浙公网安备 33010602011771号