连接数据库报ERROR 2059解决(mysql8.0.19)

本文解决MySQL 8.0中因caching_sha2_password认证插件导致的连接错误。通过修改配置文件及用户密码为mysql_native_password加密方式,实现跨平台稳定连接。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

mysql客户端连接mysql数据库时报错如下

Warning: Using a password on the command line interface can be insecure.
ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded: /home/bae/.jumbo/lib/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

(系统服务连接该数据库也会失败,mysql8.0.19)

原因

mysql8采用了新的加密方式,很多软件还不支持,将其加密方式改成原来方式即可。修改配置文件,为了长久解决问题,修改密码,配置生效。

修改配置文件,重启服务(长远解决问题)

先按照网上给的方案,修改配置文件 vi /etc/my.cnf

重启服务

service mysql stop
service mysql start

修改密码,不修改配置文件也可解决,但是只是临时。

登录连不上的mysql所在机器,进入mysql,如:mysql -h10.2.3.4 -P1234 -uroot -p1234

ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '1234'; 

其他机器再次尝试连接该mysql,系统访问该mysql都成功,问题解决

 

 

<think>我们正在讨论的是MySQL中`mysqld_safe`和`mysqld`两个进程的区别。根据引用内容,我们可以总结如下: 1. **mysqld_safe** 是一个启动脚本,用于启动和监控 **mysqld** 进程(即MySQL服务器主进程)。 2. **mysqld_safe** 是 **mysqld** 的父进程(引用[1]和引用[3])。 3.Linux系统中,当我们通过服务脚本(如`/etc/init.d/mysql start`)启动MySQL时,实际上执行的是`mysqld_safe`(引用[1])。 4. `mysqld_safe` 提供了一些安全特性,例如在服务器崩溃时自动重启,以及将错误日志重定向到文件等(引用[2]和引用[4])。 **两者核心区别**: | 特性 | mysqld_safe | mysqld (直接运行) | |--------------|------------------------------------------------|---------------------------------------| | **进程性质** | 守护进程脚本(Shell脚本) | 数据库主进程(二进制程序) | | **主要功能** | 启动、监控、重启mysqld,管理日志和错误处理 | 实际处理SQL请求和数据存储 | | **运行方式** | 作为mysqld的父进程,通过`nohup`后台运行mysqld | 可直接在前台运行(调试时) | | **崩溃恢复** | 支持自动重启(默认行为) | 自身无重启机制 | | **日志管理** | 重定向错误日志到文件(通过`--log-error`选项) | 依赖启动参数配置日志 | ### 详细解析 #### 1. **启动流程差异** - **通过`mysqld_safe`启动**(生产环境标准方式): ```bash /bin/sh /path/to/mysqld_safe --defaults-file=/etc/my.cnf ``` 该脚本会: - 解析配置文件(如`my.cnf`) - 设置环境变量(如`LD_LIBRARY_PATH`) - 用`nohup`启动`mysqld`并脱离终端(引用[3]): ```bash nohup /path/to/mysqld ... > /dev/null 2>&1 & ``` - 持续监控`mysqld`进程状态(引用[1]) - **直接运行`mysqld`**(仅限调试): ```bash /path/to/mysqld --defaults-file=/etc/my.cnf ``` - 进程直接在前台运行(占用终端) - 崩溃后不会自动重启 - 日志输出直接到终端(除非手动重定向) #### 2. **监控与容错机制** - `mysqld_safe` 会监控子进程 `mysqld` 的状态。如果 `mysqld` 意外终止(如段错误),`mysqld_safe` 会自动重启它(引用[4]展示了重启失败场景)。 - 直接运行 `mysqld` 无此保护——进程退出后服务即中断。 #### 3. **日志与错误处理** - `mysqld_safe` 强制将 `mysqld` 的标准错误(stderr)重定向到日志文件(通过 `--log-error` 指定位置),这是生产环境的关键特性(引用[4]中的错误日志路径为`/var/log/mysqld.log`)。 - 直接运行 `mysqld` 时,错误信息默认打印到控制台(除非显式配置日志文件)。 #### 4. **环境配置** - `mysqld_safe` 会在启动前设置必要的运行时环境(如库路径、核心文件生成配置),而直接运行 `mysqld` 需手动配置(引用[2]中提到的`--basedir`、`--datadir`等参数)。 --- ### 为什么生产环境必须用`mysqld_safe`? 1. **高可用保障**:自动重启机制避免服务长时间中断。 2. **日志集中管理**:确保错误日志持久化存储(关键于故障排查)。 3. **安全隔离**:通过`--user`选项以非root身份运行`mysqld`(引用[3]中`--user=mysql`)。 > **注意**:在MySQL 5.7+版本中,官方推荐使用`systemd`管理服务(如`systemctl start mysqld`),其底层仍调用`mysqld_safe`或直接集成其功能[^5]。 --- ### 操作示例:如何查看进程树 ```bash $ pstree -p | grep mysql |-mysqld_safe(6488)---mysqld(3324)-+-{mysqld}(3326) |-{mysqld}(3327) ... ``` - 进程ID 6488:`mysqld_safe`(父进程) - 进程ID 3324:`mysqld`(子进程) --- ### 常见问题分析 **Q: 为什么`mysqld_safe`会`Killed`错误?** 如引用[4]所示: ```log /usr/bin/mysqld_safe: line 183: 23638 Killed ... ``` 原因:底层`mysqld`进程被系统杀死(通常因OOM或手动`kill -9`)。此时`mysqld_safe`会尝试重启,但若资源不足将循环失败。 --- §§相关问题§§ 1. 如何配置`mysqld_safe`的自动重启策略? 2. 在`systemd`管理的系统中,`mysqld_safe`是否仍然需要? 3. `mysqld_safe`和`mysqld`的内存使用关系是怎样的? 4. 如何诊断`mysqld_safe`频繁重启`mysqld`的问题?</think>### MySQL 中 `mysqld_safe` 与 `mysqld` 进程的区别解析 #### 一、核心区别概览 | **特性** | **`mysqld_safe`** | **直接运行 `mysqld`** | |------------------|-------------------------------------------------|----------------------------------------| | **进程性质** | 守护进程脚本(Shell脚本) | 数据库主进程(二进制程序) | | **主要功能** | 启动/监控/重启 `mysqld`,提供安全保护 | 实际执行数据库操作(SQL处理、存储等) | | **运行方式** | 通过 `/bin/sh` 解释执行 | 直接执行二进制文件 | | **进程关系** | `mysqld_safe` 是 `mysqld` 的父进程(引用[1][3]) | 无父进程保护 | | **崩溃恢复** | 支持自动重启(核心功能) | 崩溃后直接退出 | | **日志管理** | 自动重定向错误日志(引用[4]) | 需手动配置日志输出 | --- #### 二、详细功能对比 1. **`mysqld_safe` 的核心作用** - **进程监控与重启** 持续监控 `mysqld` 状态,在其崩溃时自动重启(引用[4]中体现的容错机制): ```bash while true; do mysqld "$@" & # 启动mysqld wait $! # 监控退出状态 [ $? -eq 0 ] && break # 正常退出则终止循环 sleep 2 # 异常退出时等待后重启 done ``` - **安全增强** 强制以非root用户运行(通过 `--user=mysql` 参数,引用[3]),降低权限风险。 2. **`mysqld` 的核心作用** - **数据库引擎** 直接处理SQL查询、事务管理、数据存储等核心功能。 - **配置加载** 解析 `my.cnf` 配置文件,初始化存储引擎和内存池。 --- #### 三、启动流程差异(以标准服务启动为例) ```mermaid graph TD A[/etc/init.d/mysql start] --> B[调用 mysqld_safe 脚本] B --> C[/bin/sh 解释执行 mysqld_safe] C --> D[加载环境变量和配置] D --> E[用 nohup 启动 mysqld 进程] E --> F[持续监控 mysqld 状态] F -- 崩溃 --> E F -- 正常退出 --> G[结束] ``` > **关键点**: > - 直接运行 `mysqld` 会跳过蓝色流程(监控/保护层) > - 生产环境必须通过 `mysqld_safe` 启动(引用[1][3]) --- #### 四、典型场景分析 1. **崩溃恢复场景**(引用[4]) ```log /usr/bin/mysqld_safe: line 183: 23638 Killed MySQL Daemon failed to start. Starting mysqld: [FAILED] ``` - `mysqld_safe` 检测到 `mysqld` 被 `kill -9` 强制终止 - 尝试重启失败后抛出错误(若直接运行 `mysqld` 则无此提示) 2. **版本切换场景**(引用[2]) 通过 `--mysqld-version=max` 启动定制版本: ```bash mysqld_safe --mysqld-version=max # 实际启动 mysqld-max ``` --- #### 五、生产环境实践建议 1. **必须使用 `mysqld_safe` 的场景** - 高可用部署(需自动恢复) - 安全合规要求(非root用户运行) - 日志集中管理需求 2. **直接运行 `mysqld` 的调试场景** ```bash # 仅用于调试(无保护机制) /usr/sbin/mysqld --console --debug ``` > **总结**:`mysqld_safe` 是 MySQL 服务的安全守护层,提供关键的保护和运维功能;而 `mysqld` 是实际执行数据库操作的引擎进程。两者协同构成完整的 MySQL 服务[^1][^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值