暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

MySQL 5.7升级到MySQL8.0

原创 zxd1412 2023-03-08
1942
一.前期准备
1.查找本机MySQL安装
[root@localhost ~]# RPM -qa | grep -i mysql
mysql-community-libs-5.7.41-1.el7.x86_64
mysql-community-server-5.7.41-1.el7.x86_64
mysql-community-common-5.7.41-1.el7.x86_64
mysql-community-client-5.7.41-1.el7.x86_64
显示本机安装的版本是5.7.41
2.下载升级到的目标版本MySQL 8.0.27
2.1 前往官网下载升级到的版本
https://downloads.mySQL.com/archives/community/
这里如下选择:
下载下面的Tar包:
mysql-8.0.27-el7-x86_64.tar.gz
2.2 解压
执行如下命令解压Tar包:
tar xf mysql-8.0.27-el7-x86_64.tar.gz
2.3 更改目录所有者,用户组
执行如下命令更改解压目录的所有者和用户组均为mysql
chown -R mysql:mysql mysql-8.0.27-el7-x86_64
2.4 移动目录到指定工作目录
例如:mv mysql-8.0.27-el7-x86_64 /usr/mysql
二.升级前手工检查
在升级前,重点关注以下几点,并做适当的修改:
mysqlcheck 检查
不能有如下错误发生
1.1 不能有使用过时的数据类型或函数的表
1.2 不能有孤立的.frm文件
1.3 触发器不能有丢失的或空的定义符或无效的创建上下文(由SHOW Triggers或INFORMATION_SCHEMA Triggers表显示的character_set_client、collation_connection、Database collation属性指示)。必须转储和恢复任何此类触发器以解决问题。
检查以上错误,可以执行如下指令:
mysqlcheck -u root -p --all-databases --check-upgrade
执行结果如下图所示:
如果有任何错误出现,需要做相应的修正
2.分区表检查
不能有除了innodb,ndbcluster存储引擎之外的其它类型的存储引擎的分区表。要查找此类表,请执行以下查询:
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE NOT IN ('innodb', 'ndbcluster')
AND CREATE_OPTIONS LIKE '%partitioned%';
返回结果如下:
db_users t_pay_month
从返回结果上发现,有用到了非innodb和ndbcluster存储引擎的分区表。
接下来,查看此表的定义,进行确认:
CREATE TABLE `t_pay_month` (
`id` int(10) NOT NULL ,
`uid` int(10) unsigned NOT NULL ,
`payamount` int(10) unsigned NOT NULL DEFAULT '0' ,
`paytimes` mediumint(8) unsigned DEFAULT '1' ,
`postyear` smallint(6) NOT NULL ,
`postmonth` tinyint(4) DEFAULT NULL ,
`lastupdatedatetime` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP ,
PRIMARY KEY (`id`,`postyear`)
) ENGINE=MyISAM
/*!50100 PARTITION BY LIST (postyear)
(PARTITION p0 VALUES IN (2020) ENGINE = MyISAM,
PARTITION p1 VALUES IN (2021) ENGINE = MyISAM,
PARTITION p2 VALUES IN (2022) ENGINE = MyISAM,
PARTITION p3 VALUES IN (2023) ENGINE = MyISAM) */;
发现,此分区表的存储引擎为MyISAM。这里,需要将存储引擎由MyISAM改为InnoDB,修改存储引擎命令如下:
ALTER TABLE t_pay_month ENGINE=InnoDB;
当然,也可以移除分区,命令如下:
ALTER TABLE t_pay_month REMOVE PARTITIONING;
注:此处我们保留分区,仅仅修改存储引擎为InnoDB,而不移除分区。
3.关键字检查
MySQL 8.0中可能保留了一些以前未保留的关键字。请参见官方文档Section 9.3, “Keywords and Reserved Words”. 。这可能会导致以前用作标识符的单词变得非法。要修复受影响的语句,请使用标识符引号。
4.数据字典检查
MySQL 5.7 系统数据库中不能有与MySQL 8.0数据字典使用的表同名的表。要查找具有这些名称的表,请执行以下查询:
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE LOWER(TABLE_SCHEMA) = 'mysql'
and LOWER(TABLE_NAME) IN
'catalogs',
'character_sets',
'check_constraints',
'collations',
'column_statistics',
'column_type_elements',
'columns',
'dd_properties',
'events',
'foreign_key_column_usage',
'foreign_keys',
'index_column_usage',
'index_partitions',
'index_stats',
'indexes',
'parameter_type_elements',
'parameters',
'resource_groups',
'routines',
'schemata',
'st_spatial_reference_systems',
'table_partition_values',
'table_partitions',
'table_stats',
'tables',
'tablespace_files',
'tablespaces',
'triggers',
'view_routine_usage',
'view_table_usage'
5.外键约束检查
不能有外键约束名称超过64个字符的表。要查找此类表,请执行以下查询:
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME IN
(SELECT LEFT(SUBSTR(ID,INSTR(ID,'/')+1),
INSTR(SUBSTR(ID,INSTR(ID,'/')+1),'_ibfk_')-1)
FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN
WHERE LENGTH(SUBSTR(ID,INSTR(ID,'/')+1))>64);
6.SQL MODE检查
SQL_mode系统变量不能定义过时的SQL模式。尝试使用过时的SQLMODE会阻止MySQL 8.0启动。例如:不能使用NO_AUTO_CREATE_USER
7.试图检查
任何视图的显式定义列名不得超过64个字符(MySQL 5.7中允许列名最多为255个字符的视图)。为避免升级错误,应在升级前更改此类视图。目前,识别列名超过64个字符的视图的唯一方法是使用SHOW CREATE view检查视图定义。还可以通过查询信息模式VIEWS表来检查视图定义。
8.ENUM检查
任何表或存储过程的单个ENUM或SET列元素的长度不得超过255个字符或1020个字节。在MySQL 8.0之前,ENUM或SET列元素的最大组合长度为64K。在MySQL 8.0中,单个ENUM或SET列元素的最大字符长度为255个字符,最大字节长度为1020个字节。(1020字节限制支持多字节字符集)。升级到MySQL 8.0之前,请修改超过新限制的任何ENUM或SET列元素。否则将导致升级失败并出现错误。
9.共享的InnoDB表空间检查
在升级到MySQL 8.0.13或更高版本之前,共享的InnoDB表空间中必须没有表分区,其中包括系统表空间和通用表空间。通过查询INFORMATION_SCHEMA标识共享表空间中的表分区:
如果从MySQL 5.7升级,请运行以下查询:
SELECT DISTINCT NAME, SPACE, SPACE_TYPE
FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES
WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';
如果从早期的MySQL 8.0版本升级,请运行以下查询:
SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLES
WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';
使用ALTER TABLE ... REORGANIZE PARTITION:将表分区从共享表空间移动到每个表的文件表空间
10.GROUP BY子句检查
MySQL 8.0.12或更低版本中的查询和存储程序定义不能对GROUP BY子句使用ASC或DESC限定符。否则,升级到MySQL 8.0.13或更高版本可能会失败,复制到MySQL 8.0-13或更高副本服务器也可能会失败。
例如,存储过程定义如下:
CREATE PROCEDURE `usp_g_account_by_name`(i_name varchar(32))
BEGIN
SELECT uid
FROM t_account
WHERE `name` = i_name
GROUP BYuidDESC;
修改为如下:
CREATE PROCEDURE `usp_g_account_by_name`(i_name varchar(32))
BEGIN
SELECT uid
FROM t_account
WHERE `name` = i_name
GROUP BYuid
ORDER BY uid DESC;
11.服务器启动选项和系统变量检查
MySQL 5.7安装不能使用MySQL 8.0不支持的功能。
MySQL 8.0中删除了一些服务器启动选项和系统变量。请参阅See Features Removed in MySQL 8.0 和 Section 1.4, “server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.0”。如果使用了这些功能,升级需要更改配置。
例如:--ignore-db-dir选项
12.lower_case_table_names 检查
如果打算在升级时将lower_case_table_names设置更改为1,请确保schema 和表名在升级前为小写。否则,可能会由于架构或表名字母大小写不匹配而发生故障。可以使用以下查询检查包含大写字符的架构和表名:
SELECT TABLE_NAME
, IF(sha(TABLE_NAME) !=sha(lower(TABLE_NAME)),'Yes','No') AS UpperCase
FROM information_schema.tables;
从MySQL 8.0.19开始,如果lower_case_table_names=1,升级过程将检查表和模式名称,以确保所有字符都是小写的。如果发现表或架构名称包含大写字符,则升级过程将失败并出现错误。
如果由于上述任何问题导致升级到MySQL 8.0失败,服务器会将所有更改还原到数据目录。在这种情况下,删除所有重做日志文件,并在现有数据目录上重新启动MySQL 5.7服务器以解决错误。默认情况下,重做日志文件(ib_logfile*)位于MySQL数据目录中。修复错误后,在再次尝试升级之前,执行缓慢关闭(通过将innodb_fast_shutdown设置为0)。
三.升级前工具检查
上面的章节介绍了该如何逐条进行升级前的检查,下面,借助MySQL官方提供的升级检查器实用程序检查MySQL 5.7服务器实例,以及MySQL 8.0发布系列中另一个GA状态版本的MySQL 8.0服务器实例是否存在兼容性错误和升级问题,更加简单,方便。
MySQL Shell工具下载
前往官方网站,下载需要的MySQL Shell版本。
进入官方网站页面:https://www.mysql.com/downloads/
滑动至下载页面的最下面,可以看到如下:
点击【MySQL Shell】,进入下载界面,进行操作系统,版本的选择,如下:
这里,下载基于CentOS 7的rpm -ivh mysql-shell-8.0.32-1.el7.x86_64.rpm文件
2.MySQL Shell工具安装
在RPM安装工具之前,可能有安装依赖,执行如下命令解决安装依赖:
yum install -y libyaml.x86_64
之后,用如下命令正式安装MySQL Shell
rpm -ivh mysql-shell-8.0.32-1.el7.x86_64.rpm
3.启动MySQL Shell
执行如下命令:
mysqlsh
4.开启升级检查器实用程序检查
执行如下指令,进行查找。
util.checkForServerUpgrade('root@192.168.246.133:3306', {"password":"China_123456", "targetVersion":"8.0.27","outputFormat":"JSON","configPath":"/etc/my.cnf"})
注意:在MySQL Shell 8.0.20之前,用于运行升级检查器实用程序的用户帐户必须具有所有权限。从MySQL Shell 8.0.21开始,用户帐户需要RELOAD、PROCESS和SELECT权限。
解释:
targetVersion:计划升级到的版本
outputFormat:输出内容的显示格式
configPath:服务器的my.cnf或者my.ini的绝对路径
执行后,返回信息如下图所示:
因为返回内容太多,此处截取主要的部分做讲解:
"serverAddress": "192.168.246.133:3306", # 当前Server地址
"serverVersion": "5.7.41 - MySQL Community Server (GPL)", # 当前server版本
"targetVersion": "8.0.27", # 计划升级到的版本
"errorCount": 2, # 错误数量,必须修正
"warningCount": 38, # 警告数量
"noticeCount": 2,
"summary": "2 errors were found. Please correct these issues before upgrading to avoid compatibility issues.",
"checksPerformed": [ # 检查项目
"id": "oldTemporalCheck", # 检查项目
"title": "Usage of old temporal type",
"status": "OK",
"detectedProblems": []
},
"id": "routinesSyntaxCheck",
"title": "MySQL 8.0 syntax check for routine-like objects",
"status": "OK",
"detectedProblems": []
},
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"detectedProblems": []
},
"id": "nonNativePartitioningCheck",
"title": "Partitioned tables using engines with non native partitioning",
"status": "OK",
"description": "Error: In MySQL 8.0 storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in MySQL 8.0. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
"detectedProblems": [
"level": "Error",
"dbObject": "db_users.t_pay_month", #错误对象
"description": "MyISAM engine does not support native partitioning" #错误描述信息
},
"id": "groupByAscCheck",
"title": "Usage of removed GROUP BY ASC/DESC syntax",
"status": "OK",
"description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
"documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
"detectedProblems": [
"level": "Error",
"dbObject": "db_users.usp_g_account_by_name",#错误对象
"description": "PROCEDURE uses removed GROUP BY DESC syntax" #错误描述信息
},
实际上,此工具检查了所有第二章节中所提到的检查项,可以依据上述返回的检查项内容,
例如: "id": "groupByAscCheck" ,做对照查看。
依据上面的Error,做相应的修改后,再次执行以上检查命令,返回信息如下:
可以看到,已经无Error显示了。
详细的用法,参见: MySQL JS > util.help("checkForServerUpgrade")
上述命令,也可以使用如下方式执行:
mysqlsh root:China_123456@192.168.246.133:3306 -e 'util.checkForServerUpgrade({"targetVersion":"8.0.27","configPath":"/etc/my.cnf"})';
四.升级MySQL 5.7 到MySQL 8.0
下面是单机升级,高可用架构下,需要先升级从库,在从库升级无误的情况下,再升级主库。
重要:在对数据库数据做重大改变之前,升级之前,都切记做好备份,做好备份,做好备份。
完整备份数据库
执行如下命令,完整备份数据库:
mysqldump -uroot -pChina_123456 --all-databases > /root/mysql_bak/db_bak.sql
2.慢速关闭设置
登录MySQL服务器,更改参数innodb_fast_shutdown为0
mysql -u root -p --execute="SET GLOBAL innodb_fast_shutdown=0"
3.关闭数据库服务
systemctl stop mysqld
4.修改my.cnf
vi /etc/my.cnf
增加或者修改basedir为mysql指定路径
basedir=/usr/mysql
5.启动服务器
使用5.7的数据目录启动MySQL 8.0.27服务
/usr/mysql/bin/mysqld_safe --user=mysql
6.查看进程
使用如下命令来查看mysql的进程
ps aux | grep 'mysql'
结果显示如下图所示:
mysql 1574 89.2 35.8 963024 360200 pts/0 Sl+ 14:24 0:03 /usr/mysql/bin/mysqld --basedir=/usr/mysql --datadir=/usr/mysql/data --plugin-dir=/usr/mysql/lib/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
7.登录查看版本:
mysql -u root -p
执行:SELECT VERSION();
返回:8.0.27
至此,数据库成功升级到了指定的8.0.27版本。
五.升级成功后的工作
如何继续以mysqld.service方式管理数据库服务?
1.1 服务启动模式启动失败
在经过上面的操作步骤后,已经成功升级了,但是,因为旧的版本未删除,可能引起一些使用上的不便。当想以mysqld.service启动时,会存在一些问题如下:
systemctl start mysqld.service
服务无法启动,且报告如下错误信息:
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
执行如下命令,查看服务状态:
systemctl status mysqld.service
输出结果如下:
[root@localhost ~]# systemctl status mysqld.service
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Wed 2023-03-01 15:42:03 EST; 4min 17s ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 2231 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Process: 2214 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 988 (code=exited, status=0/SUCCESS)
Mar 01 15:42:03 localhost.localdomain systemd[1]: mysqld.service: control process exited, code=exited status=1
Mar 01 15:42:03 localhost.localdomain systemd[1]: Failed to start MySQL Server.
Mar 01 15:42:03 localhost.localdomain systemd[1]: Unit mysqld.service entered failed state.
Mar 01 15:42:03 localhost.localdomain systemd[1]: mysqld.service failed.
Mar 01 15:42:03 localhost.localdomain systemd[1]: mysqld.service holdoff time over, scheduling restart.
Mar 01 15:42:03 localhost.localdomain systemd[1]: Stopped MySQL Server.
Mar 01 15:42:03 localhost.localdomain systemd[1]: start request repeated too quickly for mysqld.service
Mar 01 15:42:03 localhost.localdomain systemd[1]: Failed to start MySQL Server.
Mar 01 15:42:03 localhost.localdomain systemd[1]: Unit mysqld.service entered failed state.
Mar 01 15:42:03 localhost.localdomain systemd[1]: mysqld.service failed.
从上述信息,并未得到太多的有效信息。
再继续执行如下命令:
journalctl -xe
输出结果如下:
从上面的信息中,也并未找到有用的信息。
只能看看错误日志了:
执行如下命令,查看错误日志:
cat /var/log/mysqld.log
[root@localhost mysql]# cat /var/log/mysqld.log
2023-03-01T20:41:57.426510Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2023-03-01T20:41:57.449608Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.41) starting as process 2101 ...
2023-03-01T20:41:57.449956Z 0[ERROR]Can't find error-message file '/usr/mysql/share/mysql/errmsg.sys'. Check error-message file location and 'lc-messages-dir' configuration directive.
2023-03-01T20:41:57.471166Z 0 [Note] InnoDB: PUNCH HOLE support available
2023-03-01T20:41:57.471465Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-03-01T20:41:57.471483Z 0 [Note] InnoDB: Uses event mutexes
2023-03-01T20:41:57.471511Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2023-03-01T20:41:57.471527Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2023-03-01T20:41:57.471587Z 0 [Note] InnoDB: Using Linux native AIO
2023-03-01T20:41:57.474455Z 0 [Note] InnoDB: Number of pools: 1
2023-03-01T20:41:57.475794Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2023-03-01T20:41:57.492857Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2023-03-01T20:41:57.565005Z 0 [Note] InnoDB: Completed initialization of buffer pool
2023-03-01T20:41:57.593122Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2023-03-01T20:41:57.674051Z 0[ERROR] [FATAL]InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2023-03-01 15:41:57 0x7ff7c5932780 InnoDB: Assertion failure in thread 140702148405120 in file ut0ut.cc line 921
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:41:57 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68197 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
或许,首先看到的都是上面的2个【Error】,但是,先别急着修正,让我们再往前翻看日志,发现了什么?
/usr/sbin/mysqld (mysqld 5.7.41) starting as process 2101 ...
居然还是用MySQL 5.7版本?那么下面的Error和其它一系列问题,估计就是这个原因造成的。那么我们做如下修改。
1.2 修改mysqld.service
vi /usr/lib/systemd/system/mysqld.service
修改如下:
ExecStart=/usr/mysql/bin/mysqld--daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS
#ExecStart=/usr/sbin/mysqld--daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS
修改为蓝色字体所代表的MySQL 8.0的mysqld所在完整路径。
1.3 重载脚本配置
完成上述mysqld.service的修改后,需要进行重载,执行如下命令完成:
systemctl daemon-reload
1.4 服务启动模式管理
尝试执行如下:
systemctl start mysqld.service -- 成功
systemctl restart mysqld.service -- 成功
systemctl stop mysqld.service -- 成功
2.旧的MySQL 5.7版本的删除需要注意哪些方面?
在最终确定升级成功后,MySQL 5.7的相关安装,就可以不需要保留了。
此步,需要慎重处理,最好在前一小节正常运行情况下,再进行操作。操作之前,记得做好数据库的备份工作,防止意外发生。
2.1停止服务
systemctl stop mysqld.service
2.2备份数据库文件
cd /usr/mysql
mkdir data
chown -R mysql:mysql data
cp -a /var/lib/mysql/* /usr/mysql/data/
2.3编辑并备份my.cnf
vi /etc/my.cnf
修改datadir为前一步中数据库备份的路径
datadir=/usr/mysql/data
备份my.cnf
cp /etc/my.cnf /root/bak/
2.4备份mysqld_pre_systemd
cp /usr/bin/mysqld_pre_systemd /root/bak/
2.5备份mysqld.service
cp /usr/lib/systemd/system/mysqld.service /root/bak/
2.6备份mysqld@.service
cp /usr/lib/systemd/system/mysqld@.service /root/bak/
2.7备份mysqld.pid
cp -a /var/run/mysqld /root/bak/
将mysqld.pid所在目录也一并拷贝,保留了其目录的属性,避免后期使用chown做更改。
2.8卸载mysql-community-server-5.7.41-1.el7.x86_64
执行如下命令卸载5.7版本
[root@localhost ~]# rpm -e mysql-community-server-5.7.41-1.el7.x86_64
warning: /etc/my.cnf saved as /etc/my.cnf.rpmsave
2.9还原文件
除了数据库文件之外的其它备份文件,依次拷贝回原来的路径下
cp /root/bak/my.cnf /etc/
cp /root/bak/mysqld_pre_systemd /usr/bin/
cp /root/bak/mysqld.service /usr/lib/systemd/system/
cp /root/bak/mysqld@.service /usr/lib/systemd/system/
cp -a /root/bak/mysqld /var/run/
2.10启动数据库服务
尝试执行如下:
systemctl start mysqld.service -- 成功
systemctl restart mysqld.service -- 成功
systemctl stop mysqld.service -- 成功
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论