MySQL 运维踩坑

  本文主要是介绍在 MySQL 使用运维过程中所遇到的一些坑爹的地方，予自己以做记录！

前言

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

正记二

1. 数据库中的 datetime 数据显示与实际时间相差 14 个小时，而通过 java 应用插入和查询的同一条记录，实际显示的是正确的时间 => 因此，是 mysql 相关配置的问题

   vim /etc/my.cnf
   default-time-zone = '+8:00' #在 [mysqld] 之下
   systemtcl restart mysqld #重启 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

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