一、生产环境MySQL部署问题
- 生产环境MySQL使用yum安装部署，这是大忌，因为生产环境的系统，通常硬件维护、操作系统维护都是分在不同的管理部门进行管理。作为应用厂商使用的自行维护的数据库，使用yum或rpm包安装方式安装，就意味着每次维护都需要root级别的权限，因为不管是my.cnf，还是MySQL的主程序文件，基本都在root用户权限下。每次要进行升级及维护，都需要申请root或sudo权限，这种流程是非常复杂的，因为操作系统root权限太敏感。其次即使你有了root权限，由于是生产系统，你也不大可能在升级的时候，直接yum升级，万一升级失败毫无退路可言。
- 第二个大忌，就是MySQL的目录没有规划，配置文件内容混乱，没有任何注释。目录不进行合理规划，后期很难升级，打补丁。
二、生产环境的特点及约束
- 业务连续性，数据库作为后端最重要的设施，其重要程度非常高。不论做什么操作，全库不可访问的时间，都应尽量的短，甚至是不能中断。
- MySQL这种数据库，需要根据不同的业务场景，专门进行定向优化，所以只要你是会用到MySQL的开发人员，MySQL库从部署、升级、使用、调优，必须完全掌握。
- 生产操作系统root权限，一般都是被回收管控的，不可以轻易申请到。
三、生产环境MySQL部署原则
- 规避root权限问题，MySQL应在普通用户权限下以二进制包方式或编译方式部署。
- MSQL的部署应做到程序、配置、数据三分离，做好良好的目录路径规划。通常如果不是版本跃迁式的升级，MySQL的data路径下的库存储数据文件是通用的，比如8.0.2版本的MySQL库的data路径，可以被8.0.29的直接访问，不会有什么问题。大版本内的库版本升级，通常不需要做全库导出和导入的恢复性操作。
- 数据库是非常重要的生产设施，MySQL虽然在网上有很多双主、一主多从等等的部署方案。其实在日常使用中，最稳定可靠的方案，还是主从方案。故障率最高的是双主方案。主从方案中，也不建议配置自动化的浮动IP飘动方案或切换方案。生产环境的数据库非常重要，自动化的浮动IP飘动和切换方案，经常会因为网络波动、安全扫描等各种因素，发生IP频繁飘切，影响业务稳定性，诱发业务数据层级问题。
- 要考虑到并行双测的场景。往往跨大版本数据库升级，除了在测试环境先要做演练之外。生产环境的MySQL部署时，需要考虑到多版本多实例服务器并存的要求。即为了保证秒切，或者瞬间切换，通常的做法是在MySQL所在的服务器上，再装一套目标版本MySQL实例，并且启动起来监听端口设置在不同的端口，进行调试、测试、配置、如果硬盘空间允许，还要进行数据的核查和比对，确保大部分历史数据都一致，以及比对一致点的binlog位置。然后切换时，只是把原主库停止，新库用对应的端口配置文件直接拉起，10秒左右完成切换。
四、生产环境MySQL部署知识点
4.1 MySQL的配置文件加载顺序（Linux）
从MySQL-3.X开始，MySQL的配置文件加载顺序最优先就是/etc/my.cnf，这个很关键，所以为了适应生产环境部署的特点，/etc下的MySQL配置文件最好是全部清除，会为以后多实例并行，多版本并行，安全补丁升级验证带来巨大方便。同时，把/etc/my.cnf等系统默认公共路径的配置文件删掉可以防止误操作搞坏当前库。MySQL服务启动需要读取配置文件，如果存在多个my.cnf 配置文件时，注意加载顺序。不同的大版本加载顺序稍微有差异，但基本就是这几个位置：系统公共配置路径/etc、MySQL程序安装路径、用户HOME路径、其他自定义路径下的my.cnf：
1
2
3
4
/etc/my.cnf
/etc/mysql/my.cnf
$MYSQL_HMOE/my.cnf
~/.my.cnf
注意默认是优先匹配原则，即如果它遇到了/etc/my.cnf后面的配置它就不会再去找了。不管是mysqld服务器端程序，还是MySQL客户端程序，都可以采用下面两个参数来强制指定要读取的配置文件路径：
1
2
-defaults-file=XXX，只读取指定的文件（不再读取其他配置文件）
-defaults-extra-file=XXX
从其他优先级更高的配置文件中读取全局配置后，再读取指定的配置文件（有些选项可以覆盖掉全局配置从的设定值）不建议使用，除非你能搞清楚多个配置文件之间加载覆盖的关系，否则容易发生混乱。加载细节说明：
- 没有
/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf文件，且/usr/bin/mysqld_safe和/usr/sbin/mysqld都没有指定–defaults-file的情况下，也就是没有任何配置文件的情况下所有的配置都是默认值； my.cnf会覆盖mysql.server里的basedir和datadir配置；mysqld和mysqld_safe指定–defaults-file的话，那么MySQL的配置文件就是–defaults-file对应的文件，而不是默认的/etc/my.cnf文件；mysqld或mysqld_safe命令行参数里指定的配置参数最大，其次是–defaults-file指定的my.cnf配置文件参数最大；mysqld或mysqld_safe指定参数比如–datadir参数则会覆盖/etc/my.cnf的配置；mysql.server把默认的/etc/my.cnf中的参数传递给mysqld_safe，mysqld_safe再传递给mysqld；mysql --help | grep ‘Default options’ -A 1查看my.cnf配置文件的读取顺序。
4.2 操作系统环境变量知识点
环境变量的加载顺序：系统级–>用户级–>脚本会话级，覆盖顺序刚好倒过来，越靠后的会覆盖前面的。我们修改了系统级或者用户级的环境变量时，Windows会当场立即生效（已经打开的cmd或powershell需要关闭再重开才会生效）。Linux一般是远程操作，需要关闭会话窗口重新登录使配置文件生效，或使用source 配置文件全名重新装载环境配置，例如source /etc/bashrc，使其当前立即生效。
五、生产环境MySQL安装规划及调优
5.1 安装路径规划
通常生产环境的主机都是性能比较强的PC服务器，本次安装的目标服务器CPU 48逻辑核，内存376GB，存储2TB。生产环境主机的操作系统通常安装在独立的物理盘，数据盘通常会以RAID 5或者RAID 10来组盘。程序、数据通常都不放在系统盘，要安装在数据盘。本次安装的目标服务器，数据盘挂载在/data下，我们将所有的程序和数据都有规划性的安装在数据盘里。通常数据盘的挂载路径也是直接分配给应用数据方的。/data路径下我们规划MySQL的安装路径：
| 路径 | 描述 |
|---|---|
/data/database |
历代MySQL实例程序的安装根路径。所有的MySQL不同版本实例、data数据、pid、日志、bin-log文件、sock文件全部存于此路径。 |
/data/database/mysql |
软连接，链接到当前正在主用的MySQL实例程序文件夹。也就是tar.gz解开后的二进制版程序文件夹。 |
/data/database/data |
datadir，数据库数据文件存放文件夹。初始化二进制安装程序时，指定该路径，之后初始化过程中会自动创建。 |
/data/database/log |
log-error，MySQL的日志路径，注意这个不是bin-log。 |
/data/database/binlog |
log-bin，MySQL的binlog存储路径，用于保存数据操作日志，用于库的恢复或者主从同步。 |
/data/database/mysql_data_back |
MySQL备份、导入导出等相关数据文件存储的路径。 |
/data/database/mysql_loaddata |
MySQL的数据装载与导出路径。用于业务场景，有时候直接装载文件比insert要快。 |
/data/database/my.cnf |
MySQL实例的配置文件，手动创建编写。 |
/data/database/mysql.sock |
socket，MySQL的socket文件。配置在my.cnf中，MySQL运行后会自动创建。 |
/data/database/mysql.pid |
pid-file，MySQL的pid进程号文件。配置在my.cnf中，MySQL运行后会自动创建。 |
/data/database/startMysql.sh |
MySQL实例的启动脚本，手动创建编写。 |
/data/database/stopMysql.sh |
MySQL实例的启动脚本，手动创建编写。 |
/data/database/mysql-8.0.29-el7-x86_64 |
二进制安装包解压后的路径，解压tar包自动会创建。 |
以上规划路径，除加粗的路径会在操作过程中自动生成外，其它路径均需要手动提前创建好。如果你自己也需要安装，建议你从database层开始使用该路径规划方案。这样做的好处是。首先，每次下载下来的不同版本的MySQL安装tar.gz，二进制包只会在它解压缩的文件夹位置。数据的配置文件、数据文件data、bin-log等都不在其文件夹下。当新版的实例解压测试好之后，只需要切换database/mysql的软连接指向，即可完成数据库的切换。然后放心的把以前解压的mysql-8.0.xx-el7-x86_64路径删除，生产系统路径下除了在升级时会出现两个不同版本的实例文件夹，平时不会显得乱七八糟。
很多生产环境，前仆后继的人员折腾之后，后人根本不敢清理相关文件或文件夹，因为搞不清依赖关系。其次，如果是小版本的升级或者打补丁，我们要在测试环境复原生产场景。这时，只需要把MySQL软连接指向的MySQL版本实例程序tar一份到测试环境，然后将生产的MySQL库配置导出，my.cnf拿下来参数改小。就可以做升级测试。测试无误后，就可以先部署新版本程序，然后修改软连接指向，再重启数据库即可！会给以后的运维带来极大的方便。如果遇到大版本升级，比如8.0升级到9.X或者10.X,当然它们现在都还没诞生，我们假设它向后是不兼容的。那么依然用这种路径规划。由于/etc/my.cnf已经被删除，所以我们可以很容易的在database路径下安装9.X的二进制版本，并且临时性的先将它的配置文件、数据库data路径、bin-log等都先指向到临时目录，启动脚本也可以单独写好，将实例在其它不冲突的端口拉起来，非常简单的就可以实现两个库实例的并行运行，方便生产业务、数据的迁移和并行。等到测试期、并行期结束，再进行正式割接，将文件按规划重新梳理好，将旧的MySQL删除即可。
由于startMysql.sh来启动MySQL，因此我们将MySQL依赖的重要的系统环境变量，全部设置在shell会话级，这样不管其它应用怎么魔改操作系统，都不会影响到我部署的MySQL的正常运行，因为那些有问题的环境变量，到了启动脚本就会被覆盖掉！
对于stopMysql.sh，有些人会说，不需要那么麻烦，直接kill就可以了。这是生产数据库，直接Kill，很可能会导致库表文件损坏，数据丢失等各种问题。因此专业的做法是mysqladmin命令去shutdown数据库。除非shutdown关闭不掉的挂死的情况下，也要先想办法切断MySQL的监听，比如停掉应用，或者让网络防火墙把端口挡住，过一阵CPU利用率，I/O都回落了，再kill。防止数据或表损坏。