【devOps】MySQL运维之踩坑路

 

• 前言

        因操作系统重装之后，安装了mysql5.7，而由此带来了一系列的问题，现将解决这些mysql坑的过程中一些解决办法记录下来，既是为自己后续查找问题提供方便，也是希望能够给各位猿友减少一些踩坑的过程！

 

• 正记

【ERROR-1】：for error : max_allowed_packet 

【ANSWER FOR ERROR-1】:

          （1）在mysql-cmd模式下，执行SQL命令“set global max_allowed_packet = 2*1024*1024*10;”；

        （2）并且重启mysql服务（windows下win+R -> services.msc找到MySQL重启即可；linux下执行shell命令“service mysqld restart”）

 

【ERROR-2】：for error: Incorrect string value: '\xF0\x9F...' for column 'XXX' at row

【ANSWER FOR ERROR-2】:

          （1）这是由于linux下mysql执行create table建表命令时默认采用的时latin1字符集建表的，导致一些中文字符的写入而出现的异常信息；但是在windows下，mysql默认所建的表字符是utf8的，这也是为何相同的SQL语句由windows->linux下mysql中运行抛出该异常的原因

        （2）解决该问题的是需要养成一个习惯，也即无论是什么时候什么环境下执行create table创建mysql数据库表时，务必指定特定的字符集和引擎，如SQL命令（含ENGINE=InnoDB DEFAULT CHARSET=utf8）

DROP TABLE IF EXISTS `db_test`;
CREATE TABLE `db_test` (
  `db_test_id` VARCHAR(100) NOT NULL COMMENT '测试Id',
  `db_test_text` VARCHAR(255) NOT NULL COMMENT '测试文本',
  `status` VARCHAR(2) DEFAULT '1' COMMENT '状态，1启用(默认)，-1禁用',
  `update_time` datetime  DEFAULT NULL COMMENT '更新时间',
  `create_time` datetime  NOT NULL COMMENT '创建时间',
  PRIMARY KEY (`db_test_id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='测试表';

 

【ERROR-3】：诡异描述(其实是自我错觉)之“在Springboot+Mybatis+MySQL系统架构下，某个接口的一条查询语句预期正常情况下是可以成功查询到1条返回结果的，但是只要在sql-where条件中对某个字段INDUSTRIENAME进行筛选时查询过来的结果总是0条数据，并且在navicat下手动执行该一模一样SQL语句及where条件是有1条结果的” 

=》 经过一整天的折腾：从怀疑SQL的正确性，将SQL不断拆分 -> 去除各种where条件查询均可以有结果且只要加上该字段的筛选就是0条 -> 怀疑mybatis的配置有问题 -> 结果返回java对象的映射有问题->连接的数据库地址不正确->poatman传过来的数据不是预期的那个条件值->应用控制台将SQL语句以及条件值打印出来->重启IDE、重启mysql、重启电脑->……历经了一整天的崩溃过程，一度怀疑人生一度怀疑自己的程序猿生涯之路将就此终结，万万没有想到的是自己并没有错，错的居然是因为查询的条件传过来的值是中文，，，注意是中文、中文、中文，重要的事情强调三遍 -> 于是在建立数据源连接的地方，指定字符集utf8方解决这折腾了自己一整整天的“诡异”问题，归根结底还是自己定位查问题的方式需要优化，如果能够直接去查看mysql的log将问题很快就会被发现和解决！！

【ANSWER FOR ERROR-3】:

         （0）留个心眼----尤其是MySQL数据库版本更新以及自主安装的MySQL中，特别注意当前出现的问题或者异常中有没有环节中是有中文、中文、中文的！！！！

        （1）养成良好的msyql数据源配置习惯，如：

jdbc:mysql://127.0.0.1:3306/test?characterEncoding=UTF-8

另外，需要注意的是数据源连接配置的几个选项“&autoReconnect=true&useSSL=true&useUnicode=true”等的含义及引发的问题；同时，若是中文在数据库中显示是“？”或者更新中文文字到数据库中出现异常，则是数据库的默认字符集问题，可通过SQL命令“show VARIABLES LIKE '%character%'”查看当前character-set-server的值

        （2）不仅仅要开启的是应用的SQL-log日志，更需要去开启mysql自身log以实时查看或者落日志文件，保证能够查看到最终mysql中是实际执行的SQL语句，如果这个LOG开启了，只要一查看该log就能够知道该问题是由于java-mysql连接数据源的时候未指定字符集而导致的针对中文字符串为值得查询条件时，实际执行的查询语句并非是预期的那个中文字符串而是乱码（未设置utf8导致的mysql实际接收到是乱码）

 

 

 

#Issue 1: InnoDB: The innodb_system data file 'ibdata1' must be writable

按照菜鸟教程上的MySQL教程，在CentOS7上利用RPM包安装好MySQL后第一次启动服务：

systemctl start mysqld.service

结果启动失败，查看mysql服务的启动日志：

日志位置：var/log/mysqld.log

2018-07-10T03:28:38.289394Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.11) starting as process 10959
2018-07-10T03:28:38.502207Z 1 [ERROR] [MY-012271] [InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable
2018-07-10T03:28:38.502279Z 1 [ERROR] [MY-012278] [InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable
2018-07-10T03:28:38.502331Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2018-07-10T03:28:38.502619Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2018-07-10T03:28:38.502667Z 0 [ERROR] [MY-010119] [Server] Aborting
2018-07-10T03:28:38.521513Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.11)  MySQL Community Server - GPL.

注意到第一个Error：[InnoDB] InnoDB: The innodb_system data file 'ibdata1' must be writable，可能是权限不够的原因，于是修改'ibdata1'所在文件夹的权限：

MySQL data默认路径：/var/lib/mysql

chmod -R 777 /var/lib/mysql

再次启动服务，终于启动成功。

 

【后续更新，请及时关注https://zorkelvll.cn/blogs/zorkelvll/articles/2018/11/14/1542126258699】