以前运维人员部署在生产环境的mysql又被扫描出安全漏洞，需要进行修补。这种事情本来应该是很简单的事儿，但如今执着于软件领域技术的人是越来越少，竟然没有人愿意去做去学，都想等着别人去处理，最终还是得老将出马。
上线一看，生产环境mysql竟然是yum安装部署的，这是大忌！因为生产环境的系统，通常硬件维护、操作系统维护都是分裂在不同的管理部门进行管理。作为应用厂商使用的自行维护的数据库，使用yum或rpm包安装方式安装，就意味着：每次维护都需要root级别的权限。因为不管是my.cnf，还是mysql的主程序文件，基本都在root用户权限下。每次要进行组件及维护，都需要申请root或sudo权限，这种流程是非常复杂的，因为操作系统root权限太敏感。
其次即使你有了root权限，由于是生产系统，你也不大可能在升级的时候，直接yum升级，万一升级失败毫无退路可言……数据库故障超过2个小时，通常甲方估计要暴跳如雷了！
第二个大忌，就是mysql的目录没有规划，配置文件内容混乱，没有合理的规划。光log-bin路径都前后配置了3次，几十个配置设置，没有任何注释。目录不进行合理规划，后期很难升级，打补丁。
第三从安装情况分析看，安装人员对mysql其实并没有多年的使用经验，对mysql其实并不了解。mysql一些关键的特性根本不清楚。所以多半是照着网文，一顿无理解的ctrl+c，ctrl+v，不是说cv不能做，而是作为一个负责任、有执着、致力于在软件领域长期发展的人来说，做一件事儿，就当做一次契机，当做一次对自己的验证，不断提高自己的能力才是王道。mysql这种重要的广泛的数据库工具，不说去看引擎源代码，但起码安装、使用、搭建的细节，起码要知其然，知其所以然!才能有所提高。最近看网上，都抨击Ctrl+C，Ctrl+V，但其实如果CV过程不仅是V过来，还把内容搞明白，细节搞清楚，其实是一点儿毛病都没有滴！！就怕一知半解，搞完之后，就完了，没有长进没有积累。
扯了一大堆，回归正题：正式的写一下mysql的生产环境部署要点和重要的永不过时的关键点！
生产环境的特点及约束
生产环境的特点是什么？这里给没有工作过的小白，或刚入道的小白简要的说一下。之所以扯出这个内容，是因为没有完全通用、合理的部署方案，一套方案，一定是要基于特定的约束环境下，最好或相对好的方案。
1、业务连续性第一，数据库作为后端最重要的设施，其重要程度非常高。不论做什么操作，全库不可访问的时间，都应尽量的短，甚至是不能中断！！【最重要】
2、因为第一条，衍生出了各种管理体系。通常主机硬件会归专门的团队去维护，所谓的硬件专家。主机的网络会归专门的团队维护，所谓的网络专家。主机的操作系统往往也贵专门的团队维护，所谓的系统专家。通常如果足够重要的话，数据库本身也会有专门的团队管理，所谓的DBA！当然如果应用方只有用的资格，那么其实也就没今天这篇文章什么事儿了！但为什么很多mysql库归应用方管理，而不归DBA管理呢？因为DBA不懂业务，不懂这个库是被怎么使用的，不懂有时候其实是因为懒得懂。
mysql这种数据库，需要根据不同的业务场景，专门进行定向优化，因此很多DBA懒得管到这么细致，都不愿深度介入。这种职责便会落到应用方。索性你要遇到个强硬的数据库维护团队，那估计要面对的是另外一种惨状，就是你应用觉得库参数有问题的时候，除非你对具体的参数提出具体的修改意见，否则你试图以应用现象，要求DBA对库进行调优，是不会有人理你的！因为这种强硬派的DBA团队往往就是一套通用配置打遍天下，你让它改，没有充分的理由和依据，人家根本不会理你，你自己调整你的应用去吧！
本来是要根据应用特点来进行数据库调优，就会变成，应用跟着数据库参数去改，去优化！现实生产中这类事情太多了！所以只要你是会用到mysql的开发人员，mysql库从部署、升级、使用、调优，必须完全掌握！又不是开发mysql，只是用它，用好它，知其所以然的用好它！这是对一个牵扯到mysql数据库的开发人员的基本素养要求！别扯什么细致分工，都是DBA的事儿，那不符合国情！mysql这开源小型数据库不存在这种情况！专业的DBA也都培训的是商用产品，oracle之类。君子须自强不息！
3、生产系统的操作系统root权限，一般都是被回收管控的。不可以轻易申请到，申请到一般操作也要写各种方案、报告，被监督执行，非常麻烦。相信谁都不会喜欢这种事儿。
生产环境mysql部署的原则
知道了生产环境的约束。那么部署mysql时的原则是什么呢？
1、规避root权限问题，mysql应在普通用户权限下二进制包方式或编译方式部署！
2、mysql的部署应做到程序、配置、数据三分离，做好良好的目录路径规划。通常如果不是版本跃迁式的升级，mysql的data路径下的库存储数据文件是通用的，比如8.0.2版本的mysql库的data路径，可以被8.0.29的直接访问，不会有什么问题。大版本内的库版本升级，通常不需要做全库导出和导入的恢复性操作！
3、数据库是非常重要的生产设施，mysql虽然在网上有很多双主啊、1主多从啊，等等的部署方案。其实在日常使用中，最稳定可靠的方案，还是主从方案。故障率最高的是双主方案。主从方案中，也不建议配置自动化的浮动IP飘动方案或切换方案。生产环境的数据库非常重要，自动化的浮动IP飘动和切换方案，经常会因为网络波动、安全扫描等各种因素，发生IP频繁飘切，影响业务稳定性，诱发业务数据层级问题。【这里拒绝和杠精抬杠】
4、要考虑到并行双测的场景，并不是所有的甲方都财大气粗。跨大版本升级数据库的时候，还会调硬件来。往往跨大版本数据库升级，除了在测试环境先要做演练之外。生产环境的mysql部署时，需要考虑到多版本多实例服务器并存的要求。即为了保证秒切，或者瞬间切换，通常的做法是在mysql所在的服务器上，再装一套目标版本mysql实例，并且启动起来监听端口设置在不同的端口，进行调试、测试、配置、如果硬盘空间允许，还要进行数据的核查和比对，确保大部分历史数据都一致，以及比对一致点的binlog位置。然后切换时，只是把原主库停止，新库用对应的端口配置文件直接拉起，10秒左右完成切换。
mysql生产环境部署的背景知识点
1、mysql的配置文件加载顺序（linux）
从mysql3.X开始，mysql的配置文件加载顺序最优先就是 /etc/my.cnf ！这个很关键，所以为了适应生产环境部署的特点，/etc下的mysql配置文件最好是全部清除！会为以后多实例并行，多版本并行，安全补丁升级验证带来巨大方便。
当然有人会说，可以用-defaults-file=#来指定啊！我只想说，你命令都要带这么个参数的时候，你觉得方便么？不怕误操作么？本来是想对新装的实例动作的，结果不小心参数忘了，搞了生产正在用的库……悲剧了……谁也不愿工作的时候发生悲剧对吧！从安装开始，就考虑到各种可能的情景，然后进行保护性设计和规划，这才是一个高手的表现。仅仅只是对数据库产品本身了解，并不能成为一个优秀的DBA！
MySQL 服务启动需要读取配置文件，如果存在多个 my.cnf 配置文件时，加载顺序。注意不同的大版本加载顺序稍微有差异。但基本就是这几个位置。系统公共配置路径/etc，mysql程序安装路径，用户HOME路径：
/etc/my.cnf
/etc/mysql/my.cnf
$MYSQL_HMOE/my.cnf
~/.my.cnf
其他自定义路径下的my.cnf，例如：/data/mysql/yejr_3306/my.cnf。注意默认是优先匹配原则，即如果它遇到了/etc/my.cnf后面的配置它就不会再去找了。不管是mysqld服务器端程序，还是mysql客户端程序，都可以采用下面两个参数来强制指定要读取的配置文件路径：
-defaults-file=#， 只读取指定的文件（不再读取其他配置文件）
-defaults-extra-file=#， 从其他优先级更高的配置文件中读取全局配置后，再读取指定的配置文件（有些选项可以覆盖掉全局配置从的设定值）不建议使用，除非你的脑容量很大，能搞清楚多个配置文件之间加载覆盖的关系！谁也不愿搞个数据库，到底实例装载的配置情况是哪个配置文件的在生效，自己不掌控吧！
加载细节说明：
1、没有/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、 ~/.my.cnf文件，且/usr/bin/mysqld_safe和/usr/sbin/mysqld都没有指定–defaults-file的情况下，也就是没有任何配置文件的情况下所有的配置都是默认值；
2、my.cnf会覆盖mysql.server里的basedir和datadir配置；
3、mysqld和mysqld_safe指定–defaults-file的话，那么mysql的配置文件就是–defaults-file对应的文件，而不是默认的/etc/my.cnf文件；
4、mysqld或mysqld_safe指定参数比如–datadir参数则会覆盖/etc/my.cnf的配置；
5、mysql.server把默认的/etc/my.cnf中的参数传递给mysqld_safe，mysqld_safe再传递给mysqld；
6、mysql --help | grep ‘Default options’ -A 1 查看my.cnf配置文件的读取顺序。简单概括一下：mysqld或mysqld_safe命令行参数里指定的配置参数最大，其次是–defaults-file指定的my.cnf配置文件参数最大。这个是后续部署规划中，非常重要的知识点需要牢记！
看完上述原因，细心并用心的人应该已经明白了。把/etc/my.cnf等系统默认公共路径的配置文件删掉是上策。可以防止误操作，可以防止二货小白上来瞎搞的时候，搞坏当前库。
当然把生产库实例的配置放在/etc/my.cnf就是大忌了！万一有二货上服务器部署没注意，新版的程序就会按你的公共配置加载，然后事儿就整大了，各种不可预知的故障，可能最终要导致库重装！
2、操作系统环境变量知识点
很多时候，由于硬件紧张，我们并不能做到mysql这种库也单机部署，然后就会遇到操作系统环境变量必须容忍其它程序组件的情况。比如时区设置，比如最重要的字符编码集，等等。这时候，基础知识又要显神威了！
windows和linux差不多，只不过windows是在我的电脑，系统高级属性里设置环境变量，最经典的大多数人都改过PATH。以前只有系统级，现在还分为用户级。
linux的最关键的环境变量文件是4个，也是分系统级和用户级。系统级在/etc/profile;/etc/bashrc;用户级在用户的home目录下的隐藏文件.bash_profile;.bashrc。
加载顺序和mysql配置文件类似，优先是系统级，然后是用户级，之后是会话级。不同之处在于，它是逐级覆盖，也就是说最后加载的可以覆盖之前的。比如系统级我配置的有PATH变量，到用户级还有PATH变量，到bat或shell里还有PATH变量，这时加载过程是3个变量都会被依次加载，最终的shell里的PATH变量会覆盖以前的2个。
这个特性会被大量应用在生产环境的工程、程序部署方面。用来隔离环境变量对自身组件的影响。通常的建议是，除了真正的公共配置，一般单独的组件的环境变量，最好是配置在组件自己的启动脚本里，这样可以防止，二货魔改系统级环境变量，或用户级环境变量之后，组件不能正常工作的问题。
通常由于root权限是不会给应用使用方的，所以系统级的环境变量，通常也是我们无法修改的，但如果必要的话，我们可以在自己的脚本或者会话环境中，覆盖或重新指定需要的环境变量的值！这一点一定要牢记，并活学活用。可以帮助你在日后的工作中解决大量的冲突类问题，同时也会让你在部署规划时，比别人更胜一筹。你规划部署的环境，不论是使用，还是日后维护，都比其它人的工作量要轻很多。
当我们修改了系统级或者用户级的环境变量时，windows会当场立即生效（已经打开的cmd或powershell需要关闭再重开才会生效）。linux一般是远程操作，需要关闭会话窗口重新登录使配置文件生效，或使用 source 配置文件全名 重新装载环境配置，使其当前立即生效。
一般情况下，linux中我们是用source命令来让配置立即生效，因为有些环境变量配置如果改动不合理，会导致会话无法登录……而发生悲剧（要惊动系统或主机维护的部门来使用KVM或进机房操作主机恢复设置，通常这么搞，就会被要求写各种报告、检查、保证书……甚至公司被扣款）。所以谨慎的操作方式是开2个会话窗口，一个窗口改后source验证，不出问题。然后再新开会话，也不影响登录和操作，都没问题，就算正常。linux有个好处就是，通常已经连通的会话，它发生改变时，是不会强制切断的。
笔者多次升级ssh服务，都是靠多开几个窗口备用，顺利活到今天的！！
所以操作习惯很重要，尤其是修改系统级配置，一定要多开几个窗口，留着备用！
多开几个窗口备用！！
多开几个窗口备用！！！
重要的事儿说三遍！
当然升级ssh之前，开启telnet服务，并验证无误，也是另一重保障！
强调一下，环境变量的加载顺序：系统级-->用户级-->脚本会话级，覆盖顺序刚好倒过来，越靠后的会覆盖前面的！
source /etc/bashrc 配置文件立即生效！
知道了这些知识点之后，我们开始安装mysql8！其实安装过程很简单，原则很重要！
mysql8安装前准备工作
1、系统环境检查&安装包准备
本次以mysql8.0.29为例，首先到mysql的官方网站，找到安装指引：
找到我们需要的二进制方式安装说明：
找到注意选项：
可以看到，对系统的安装要求是必须要检查libaio是否已安装。需要提前安装libaio。
本次安装mysql8的操作系统，是苏研的BC Linux。宣称是国产系统，其实大家都清楚，这里多的就不说了，这系统就对应CentOS 7，RedhatLinux 7走就ok，内核版本3.10；
确定完操作系统，然后到
mysql的下载页首先我们看一下linux Generic通用安装程序，发现通用安装版的二进制编译版是依赖不同的glibc版本，因此还要查看一下操作系统的glibc版本。
一阵命令操作：
可以看到，系统的glibc版本是2.17版本，那么下载的时候，自然就应该选择对应的：
Linux - Generic（gibc 2.17）（x86,64-bit）
的安装包。但其实刚才说了，虽然是国产操作系统，但其实就是RedhatLinux 7。
所以最终决定，还是下载RedhatLinux 7对应的mysql 8.0.29的二进制版安装包，以便获得更好的稳定性。
在下载页面选择：
下载后得到安装文件：
mysql-8.0.29-el7-x86_64.tar.gz
上传到服务器，准备安装。
2、安装路径规划
通常生产环境的主机都是性能比较强的PC服务器，本次安装的目标服务器CPU 48逻辑核，内存376GB，存储2TB。
生产环境主机的操作系统通常安装在独立的物理盘，数据盘通常会以RAID 5或者RAID 10来组盘。程序、数据通常都不放在系统盘，要安装在数据盘。
本次安装的目标服务器，数据盘挂载在/data下，我们将所有的程序和数据都有规划性的安装在数据盘里。通常数据盘的挂载路径也是直接分配给应用数据方的。
/data路径下我们规划mysql的安装路径：
| 路径 | 说明 |
| /data/database | 历代mysql实例程序的安装根路径。所有的mysql不同版本实例、data数据、pid、日志、bin-log文件、sock文件全部存于此路径。 |
| /data/database/mysql | ln -s 创建的软连接，链接到当前正在主用的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包自动会创建。 tar -zxvf mysql-8.0.29-el7-x86_64.tar.gz会自动生成。 |
以上规划路径，除加粗的路径会在操作过程中自动生成外，其它路径均需要手动提前创建好。如果你自己也需要安装，建议你从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删除即可。
所以其实mysql要用好，日常我们做为开发人员自己搭开发环境时，完全可以使用docker很方便也不用在意这么多细节。而一旦遇到生产环境，我们必须打起12分精神，仔细考虑，不仅要考虑当下，还要考虑未来漏洞修补、版本升级、数据迁移、备份、日常维护、主从同步以及切换等。
如果服务器复用，那么还需要考虑环境变量冲突。比如本次操作的生产服务器，上面就部署有古老的web应用，要求操作系统字符编码集必须是GBK，还有一些七七八八的操作系统环境变量配置。为了防止这些配置影响到mysql的安装和运行，因此startMysql.sh启动脚本来规避这类问题，就再好不过。同时还能防止其它应用魔改操作系统环境变量。
由于startMysql.sh来启动mysql，因此我们将mysql依赖的重要的系统环境变量，全部设置在shell会话级，这样不管其它应用怎么魔改操作系统，都不会影响到我部署的mysql的正常运行，因为那些有问题的环境变量，到了启动脚本就会被覆盖掉！
对于stopMysql.sh，有些人会说，不需要那么麻烦，直接kill就可以了。我只想说，直接kill真的太不专业了！这是生产数据库，直接Kill，很可能会导致库表文件损坏，数据丢失等各种问题。因此专业的做法是mysqladmin命令去shutdown数据库。除非shutdown关闭不掉的挂死的情况下，也要先想办法切断mysql的监听，比如停掉应用，或者让网络防火墙把端口挡住，过一阵cpu利用率，I/O都回落了，再kill。防止数据或表损坏
3、安装
3.1 initialize前准备工作
做好上面的路径规划准备步骤之后。安装就很简单了。
- 首先，将下载的mysql-8.0.29-el7-x86_64.tar.gz复制到/data/database
- 然后运行tar命令解压缩 "tar -zxvf mysql-8.0.29-el7-x86_64.tar.gz"
tar -zxvf mysql-8.0.29-el7-x86_64.tar.gz- 在/data/database路径下就会生成子文件夹：/data/database/mysql-8.0.29-el7-x86_64
- 执行 " ln -s" ，创建mysql软链
ln -s mysql-8.0.29-el7-x86_64 mysql- 设置系统环境变量方便操作
首先是修改用户级环境变量 ~/.bash_profile
[bdusr@localhost ~]$ cat .bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
#PATH=$PATH:$HOME/.local/bin:$HOME/bin
#注释掉以前的PATH，声明MYSQL_HOME变量，然后配置在PATH路径的最开始，这样就可以免去检查mariaDB是否安装的问题
MYSQL_HOME=/data/database/mysql
PATH=$MYSQL_HOME/bin:$PATH:$HOME/.local/bin:$HOME/bin
export PATH
针对程序账号用户级的环境变量设置，声明MYSQL_HOME环境变量，并放于PAHT的最前面。这样安装过程中就不会被mariaDB或者其它yum或rpm安装的mysql工具路径所干扰。
细心的同学应该已经知道了，如果后续要安装多实例的情形，要么要在安装时会话窗口内设置PATH，要么就要在新的mysql实例的操作脚本中，声明PATH，就可以做到，既不影响已有的实例正常运行和操作，又能自己方便的操作新增的实例的目的。
接下来我们处理用户级环境变量~/.bashrc
alias mysql='LANG=en_US.UTF-8; mysql --defaults-file=/data/database/my.cnf '
shopt -s expand_aliases在末尾增加这个内容。主要原因是，本次操作的服务器，服务器本身部署有web应用，前端开发要求操作系统语言环境必须是GB2312，而mysql安装最好是在操作系统语言字符变化环境UTF-8下，并且操作也最好是在UTF-8字符集下。因此，我们对mysql进行重定义，让它先改变当前会话的字符编码集设置，再执行命令。同时我们强制指定my.cnf的位置，来防止没有清理的/etc/my.cnf影响我们的安装过程。
- 设置ulimt参数，防止ulimit限制数据库性能
服务配置 /etc/systemd/system.conf
用户配置 /etc/systemd/user.conf
PAM模块配置文件
/etc/security/limits.conf
/etc/security/limits.d/20-nproc.conf
以上几个文件都需要配置修改，主要是调整增大进程数、文件句柄数。
初始化数据库前的准备工作就做好了！
3.2 initialize初始化数据库实例
前面准备工作做好后，接下来就简单了，一句命令直接完事：
[bdusr@localhost database]$ mysqld --initialize --user=bdusr--lower-case-table-names=1 --basedir=/data/database/mysql --datadir=/data/database/data
2022-06-12T04:02:22.707503Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2022-06-12T04:02:22.707647Z 0 [System] [MY-013169] [Server] /data/database/mysql-8.0.29-el7-x86_64/bin/mysqld (mysqld 8.0.29) initializing of server in progress as process 692643
2022-06-12T04:02:22.716435Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-06-12T04:02:22.910043Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-06-12T04:02:24.060870Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: epe2=x<aivFamysqld --initialize --user=username --lower-case-table-names=1 --basedir=/data/database/mysql --datadir=/data/database/data
注意：命令中的 --user=username；username应该是你当前正在使用的操作系统的账号。也就是你生产业务服务器中生产环境部署程序的账号，通常叫程序账号。这样便于以后你登陆维护，整个mysql进程都会属于这个用户。本次使用的是当前操作的程序账号bdusr。
命令中 --lower-case-table-names=1 是因为my.cnf中，我们要开启表名大小写敏感，这个不能在后期设置，必须在安装阶段初始化时进行设置，否则my.cnf中不可以配置该属性，配置了库会启动失败。
命令中最关键是basedir，我们使用了软链接地址，为以后的升级、维护做好铺垫。
至于datadir当然是按规划来了，不要提前创建好路径，data路径命令执行后mysql会自行创建！！
初始化语句执行完成的最后一句： “A temporary password is generated for root@localhost: epe2=x<aivFa”，这个一定要牢记。这是mysql的root本地用户登录的临时密码，一会儿我们需要在本地使用mysql客户端登录配置用户等，第一次登录，需要使用到这个密码，并且第一次登录做其它任何操作之前，都必须先改密码，否则是无法操作的。
3.3 创建my.cnf并启动数据库
接下来在database路径下创建一个my.cnf文件，笔者安装时使用的用户叫bdusr内容如下：
[bdusr@localhost database]$ cat my.cnf
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
max_heap_table_size=128M
table_open_cache=8000
tmp_table_size = 16M
read_rnd_buffer_size=16M
datadir = /data/database/data
socket = /data/database/mysql.sock
lower_case_table_names = 1
open_files_limit = 100000
binlog_cache_size = 20971520
log-error = /data/database/log/mysqld.err
pid-file = /data/database/mysqld.pid
#skip_grant_tables
innodb_flush_log_at_trx_commit = 0
port = 3306
expire_logs_days=3
character-set-server = UTF8MB4
user = bdusr
binlog-ignore-db=mysql
log-slave-updates = on
slave-skip-errors=all
sync_binlog=100
max_connections=500
max_connect_errors=1000000
default-storage-engine=INNODB
max_allowed_packet=128M
innodb_buffer_pool_size=100G
innodb_buffer_pool_instances=50
innodb_buffer_pool_chunk_size=1G
sort_buffer_size=16M
max_length_for_sort_data=8096
innodb_sort_buffer_size=64M
myisam_sort_buffer_size=64M
join_buffer_size=8M
read_buffer_size=8M
log-bin=/data/database/binlog/mysql-bin.log
wait_timeout=36000
interactive_timeout=36000
#不使用X plugin协议，不用监听33060端口!
mysqlx=0
mysqlx_interactive_timeout=36000
mysqlx_wait_timeout=36000
#skip-grant-tables
[mysql]
# 设置mysql客户端默认字符集
default-character-set = utf8mb4
socket = /data/database/mysql.sock
[client]
socket = /data/database/mysql.sock
port = 3306
default-character-set = UTF8MB4该配置是针对此次的服务器结合业务定向优化过的。比较乱，但内容没问题。就用该配置文件编写启动脚本，启动mysql。
创建startMysql.sh
#!/bin/sh
LANG=en_US.UTF-8
MYSQL_HOME=/data/database/mysql
PATH=$MYSQL_HOME/bin:$PATH
mysqld --defaults-file=/data/database/my.cnf &创建stopMysql.sh
#!/bin/sh
LANG=en_US.UTF-8
MYSQL_HOME=/data/database/mysql
PATH=$MYSQL_HOME/bin:$PATH
mysqladmin --defaults-file=/data/database/my.cnf -uroot -p shutdown
echo '查询进程ID和端口监听,没有正常退出的话，自己kill吧！'
echo 'ps -ewf | grep mysqld'
ps -ewf | grep mysqld
echo 'netstat -na |grep 13306'
netstat -na |grep 13306启动mysql，然后看log下的日志文件内容。
2022-06-12T04:08:26.853129Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2022-06-12T04:08:26.853157Z 0 [Warning] [MY-011068] [Server] The syntax 'log_slave_updates' is deprecated and will be removed in a future release. Please use log_replica_updates instead.
2022-06-12T04:08:26.853170Z 0 [Warning] [MY-011068] [Server] The syntax 'slave_skip_errors' is deprecated and will be removed in a future release. Please use replica_skip_errors instead.
2022-06-12T04:08:26.853242Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2022-06-12T04:08:26.853371Z 0 [System] [MY-010116] [Server] /data/database/mysql-8.0.29-el7-x86_64/bin/mysqld (mysqld 8.0.29) starting as process 694070
2022-06-12T04:08:26.866743Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-06-12T04:11:10.504089Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-06-12T04:11:10.819926Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2022-06-12T04:11:10.819982Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2022-06-12T04:11:10.848442Z 0 [System] [MY-010931] [Server] /data/database/mysql-8.0.29-el7-x86_64/bin/mysqld: ready for connections. Version: '8.0.29' socket: '/data/database/mysql.sock' port: 13306 MySQL Community Server - GPL.查看监听是否正常，因为my.cnf里设置了端口为13306，因此运行看13306端口监听是否正常：
[bdusr@localhost log]$ netstat -na|grep 13306
tcp6 0 0 :::13306 :::* LISTEN
可以看到端口监听正常，那么我们就可以开始使用mysql客户端连接我们的实例。
3.4 mysql数据库实例root用户初次登录设置
[bdusr@localhost database]$ mysql -uroot -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.29
Copyright (c) 2000, 2022, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
mysql> 使用“ mysql -uroot -p ” 命令登录我们安装好的mysql数据库，输入之前初始化数据库时最后一行信息提供的root用户密码 epe2=x<aivFa
如上面代码段所示，成功登陆。说明库已经安装初始化完成，接下来执行 show database；mysql就会报错了。原因是在操作之前必须要先重置root用户的密码，不能使用临时密码！
所以需要执行一下alter语句，改个密码：
mysql> show databases;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
mysql> alter user 'root'@'localhost' identified with mysql_native_password by '1qaz@WSX';
Query OK, 0 rows affected (0.00 sec)
mysql> 可以看到，提示操作ok，只有alter修改密码能正常执行，其它语句都会报上面的错误。修改之后，我们就可以愉快的操作数据库了！
3.5 使用测试
比如查看一下mysql当前初始化完有几个用户：
mysql> alter user 'root'@'localhost' identified with mysql_native_password by '1qaz@WSX';
Query OK, 0 rows affected (0.00 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
mysql> use mysql;
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> show tables;
+------------------------------------------------------+
| Tables_in_mysql |
+------------------------------------------------------+
| columns_priv |
| component |
| db |
| default_roles |
| engine_cost |
| func |
| general_log |
| global_grants |
| gtid_executed |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| innodb_index_stats |
| innodb_table_stats |
| password_history |
| plugin |
| procs_priv |
| proxies_priv |
| replication_asynchronous_connection_failover |
| replication_asynchronous_connection_failover_managed |
| replication_group_configuration_version |
| replication_group_member_actions |
| role_edges |
| server_cost |
| servers |
| slave_master_info |
| slave_relay_log_info |
| slave_worker_info |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+------------------------------------------------------+
37 rows in set (0.00 sec)
mysql> select Host,User,authentication_string from user;
+-----------+------------------+------------------------------------------------------------------------+
| Host | User | authentication_string |
+-----------+------------------+------------------------------------------------------------------------+
| localhost | mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED |
| localhost | mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED |
| localhost | mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED |
| localhost | root | *84655C886919C05CA1A6AF355A92E72A91AA5423 |
+-----------+------------------+------------------------------------------------------------------------+
4 rows in set (0.00 sec)
mysql> 可以看到操作一切顺利！有的同学可能发现密码1qaz@WSX的authentication_string和我的不一样，那是因为写博文的原因，我设置的实际密码并不是1qaz这样的一个弱密码。root用户很关键，所以密码最好设置复杂一些。
3.6 stopMysql.sh脚本测试
通过上面的步骤，整个数据库已经安装好运行好，root密码也已经改成我们自己设置的了。接下来，测试一下stop脚本是否能正常模式把库关闭。
[bdusr@localhost database]$ ./stopMysql.sh
Enter password:
查询进程ID和端口监听,没有正常退出的话，自己kill吧！
ps -ewf | grep mysqld
xjbd 694070 1 1 12:08 pts/3 00:00:24 [mysqld]
xjbd 699868 699834 0 12:29 pts/3 00:00:00 grep mysqld
netstat -na |grep 13306
[bdusr@localhost database]$ netstat -na|grep 13306
[bdusr@localhost database]$ ls
binlog data log my.cnf mysql mysql-8.0.29-el7-x86_64 mysql_data_bak startMysql.sh stopMysql.sh
[bdusr@localhost database]$ ./startMysql.sh
[bdusr@localhost database]$ ls
binlog log mysql mysql_data_bak mysql.sock startMysql.sh
data my.cnf mysql-8.0.29-el7-x86_64 mysqld.pid mysql.sock.lock stopMysql.sh可以看到stop脚本工作正常，执行后，数据库就被关闭了。端口监听查询不存在，并且database路径下的pid文件sock文件都会自动消失了。
再次启动mysql，然后ls看一下database路径，一切正常。pid文件生成、sock文件生成！
至此Mysql8.0.29在生产环境的安装就完成了！
4、配置文件调参
本次安装使用的my.cnf是生产用配置，为了一些特定性能，一些参数配置的都很大，比如
innodb_buffer_pool_size=100G
innodb_buffer_pool_instances=50
至于详细的参数文件的整理、参数调整、主从配置，请静待后续分享。