MySQL 数据文件迁移至新硬盘

[mysqld]

# * Basic Settings

user            = mysql

pid-file        = /var/run/mysqld/mysqld.pid

socket          = /var/run/mysqld/mysqld.sock

port            = 3306

basedir        = /usr

datadir        = /data/c/mysql 修改

#datadir        =/var/lib/mysql

这个原因有二，其中任意的一个原因都会造成你被系统告知这个warning。如果你不是一个专业的linux系统安全工程师，或者你只是个PHP程序员，并没有对系统安全有深入的研究，你就不会太容易找到它的答案。

第一，selinux，记得当年念书时，字符界面安装redhat（很古老的操作系统么。。。）的时候，有这么一个选项，通常大家都听取前辈的建议，改变默认值以不安装它。但如果你恰好要操作的这台机器开着selinux，它确实能够使你的mysql无法在新目标位置进行mysql_install_db的操作，并爆出标题所示的警告。一个简单的解决办法是使用命令暂时关闭selinux，以便让你的操作可以继续下去 setenforce 0 但最好使用一个永久方法，以便在重启后继续不要这货。 修改/etc/selinux/config文件中设置SELINUX=disabled ，然后重启或等待下次重启。

第二，apparmor，这个坑爹货和selinux一样的坑爹，它也对mysql所能使用的目录权限做了限制 在 /etc/apparmor.d/usr.sbin.mysqld 这个文件中，有这两行，规定了mysql使用的数据文件路径权限

/var/lib/mysql/ r, /var/lib/mysql/** rwk,

你一定看到了，/var/lib/mysql/就是之前mysql安装的数据文件默认路径，apparmor控制这里mysqld可以使用的目录的权限 我想把数据文件移动到/data/mysql下，那么为了使mysqld可以使用/data/mysql这个目录，照上面那两条，增加下面这两条就可以了

/data/mysql/ r, /data/mysql/** rwk,

  /var/lib/mysql/ r,

  /var/lib/mysql/** rwk,

  /datc/c/mysql/ r,

  /data/c/mysql/** rwk,

  /var/lib/mysql-files/ r,

  /var/lib/mysql-files/** rwk,

  /data/c/mysql-files/ r,

  /data/c/mysql-files/** rwk,

  /var/lib/mysql-keyring/ r,

  /var/lib/mysql-keyring/** rwk,

  /data/c/mysql-keyring/ r,

  /data/c/mysql-keyring/** rwk,

apparmor，/etc/inid.d/apparmor restart////////////     /etc/init.d/apparmor restart

caching_sha2_password认证插件提供更多的密码加密方式，并且在加密方面具有更好的表现，目前MySQL 8.0选用caching_sha2_password作为默认的认证插件，MySQL 5.7的认证插件是MySQL_native_password。如果客户端版本过低，会造成无法识别MySQL 8.0的加密认证方式，最终导致连接问题。

MySQL存储引擎现在负责提供自己的分区处理程序，而MySQL服务器不再提供通用分区支持，InnoDB和NDB是唯一提供MySQL 8.0支持的本地分区处理程序的存储引擎。 如果分区表用的是别的存储引擎，存储引擎必须进行修改。要么将其转换为InnoDB或NDB，要么删除其分区。通过MySQLdump从5.7获取的备份文件，在导入到8.0环境前，需要确保创建分区表语句中指定的存储引擎必须支持分区，否则会报错。

MySQL 8.0的默认字符集utf8mb4，可能会导致之前数据的字符集跟新建对象的字符集不一致，为了避免新旧对象字符集不一致的情况，可以在配置文件将字符集和校验规则设置为旧版本的字符集和校验规则。

MySQL 8.0启动使用的lower_case_table_names值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。

< lower_case_table_names >

https://dev.mysql.com/doc/refman/8.0/en/server-systemvariables.html#sysvar_lower_case_table_names

要避免MySQL 8.0上的启动失败，MySQL配置文件中的sql_mode系统变量不能包含NO_AUTO_CREATE_USER。

从MySQL 5.7.24和MySQL 8.0.13开始，MySQLdump从存储程序定义中删除了NO_AUTO_CREATE_USER。必须手动修改使用早期版本的MySQLdump创建的转储文件，以删除NO_AUTO_CREATE_USER。

在MySQL 8.0.11中，删除了这些不推荐使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。从5.7到8.0的复制场景中，如果语句使用到废弃的SQL Mode会导致复制异常。

在执行到MySQL 8.0.3或更高版本的in-place升级时，BACKUP_ADMIN权限自动授予具有RELOAD权限的用户。

本文对MySQL 5.7到MySQL 8.0的升级过程中出现部分易出现问题进行整理：升级对MySQL版本的要求、升级都做了哪些内容、数据库升级做了哪些步骤以及注意事项，希望对大家版本升级有帮助。

---