MySQL8.4设置密码规则为mysql_native_password问题
|
MySQL8.4设置密码规则为mysql_native_password
mysql使用的时候会有报错:- Plugin 'mysql_native_password' is not loaded
复制代码 1) 首先确认mysql_native_password插件是否已经安装
安装mysql_native_password插件- INSTALL PLUGIN mysql_native_password SONAME 'mysql_native_password';
复制代码 如果已经安装,会显示该插件已经存在
2) 查看插件状态看看mysql_native_password插件的状态是不是ACTIVE,如果状态值为DISABLED则说明插件没有激活
3) 修改my.cnf或my.ini配置文件- [mysqld]
- mysql_native_password=ON #添加此行
复制代码 不要添加default_authentication_plugin=mysql_native_password,否则mysql会无法启动。
4) 重启mysql服务
5) mysql命令行查看用户使用的插件- select user,host,plugin from mysql.user;
复制代码 6) 修改密码认证方式- ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your password';
- FLUSH PRIVILEGES; #刷新权限
复制代码 MySQL8.4新特性速览
目前,可以在Oracle官网查看到MySQ 8.4新增的内容:
https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/mysql-nutshell.html
这里选一些重点变化项聊一下。
1.MySQL密码认证变更
从 MySQL 8.4.0 开始,mysql_native_password 认证插件默认不再启用。
若要启用,需要在MySQL启动的时候,添加–mysql-native-password=ON 参数;
或在配置文件中设置 mysql_native_password=ON。
2.一些系统变量默认值变更
MySQL 8.4,还调整了与 InnoDB 存储引擎相关的多个服务器系统变量的默认值,比如:
- 默认值改成了10000,之前是200。
- 控制每秒可用于 InnoDB 后台任务的 I/O 数。
- 比如缓冲池中的页面刷新,或者合并来自更改缓冲区的数据。
- 如果是 SSD,可设置 5000 以上。
- 现在线上MySQL,基本都是SSD,所以默认值设置成10000也合理。
- innodb_buffer_pool_instances
复制代码
- InnoDB 缓冲池的区域数,将缓冲池划分多个区域,可以减少不同线程读取和写入缓存页时的争用,可提高并发性。
- 之前默认值是8,如果innodb_buffer_pool_size< 1G,则为1。
- 从8.4开始,如果innodb_buffer_pool_size<= 1G,则为1;
- 如果innodb_buffer_pool_size>1G,则是在下面两个计算中,选一个最小值:
- innodb_buffer_pool_size innodb_buffer_pool_chunk_size这个结果的1/2;
- 可用逻辑CPU数量的1/4。
- 决定哪些操作会使用change buffer,有关change buffer,我们在前面详细介绍过:一文弄懂MySQL更改缓冲区。
- 之前的版本默认值是all,表示innodb_change_buffering会缓存插入、删除标记操作和后台发生的物理删除操作。
- 从8.4开始,默认是none,表示不缓存这些修改操作,这个不太理解,大家可以在留言区讨论,可能考虑什么因素。
3.克隆插件
克隆插件的版本要求放宽,允许在同一大版本号下的不同小版本之间进行克隆。
4.组复制相关
group_replication_set_as_primary变化
使用group_replication_set_as_primary() 选举新主节点前,会等待正在进行的 DDL 语句完成。当然,这个是从8.1开始有的特性。
参数group_replication_consistency默认值变更
默认值改成了BEFORE_ON_PRIMARY_FAILOVER,以前是EVENTUAL。
这里补充一下group_replication_consistency几个值的介绍:
- :事务提交后会广播到集群的多数节点,然后节点检查是否有冲突,如果没有冲突,则事务在本地提交,其他节点异步处理,可能导致读取到稍旧的数据。
- BEFORE_ON_PRIMARY_FAILOVER
复制代码 :在主节点故障时,必须等待新主处理完待处理的事务,才能开始响应业务的读写请求,这样可以保证业务读写请求不会读取到旧数据。
- :一个事务会等待之前的事务执行完后再开始执行,确保读取到的数据是最新的。
- :写事务会等待其更改在所有其他节点应用后才提交,保证后续事务读取已写入或其他节点上最新的值。对只读事务没有影响
- :会等待之前的事务执行完后才开始执行新事物,并等到事务在所有节点应用后才提交,确保读取和提交都具有强一致性。
参数group_replication_exit_state_action默认值变更
group_replication_exit_state_action 默认值改成了OFFLINE_MODE,以前是READ_ONLY。
这个参数控制了MGR实例处理故障节点的方式,有三个选项:
- 设置为read_only时,会把这个实例的super_read_only设置为on;
- 设置为offline_mode时,会把这个实例切换到离线模式
- 设置为abort_server时,将关闭MySQL。
我们可以回顾一下MGR的故障检测流程:
也就是当一个节点出现故障之后,进行group_replication_autorejoin_tries参数配置的自动重连次数之后。
这个节点的行为,之前默认情况下,是设置为super_read_only,现在是会把实例切换到离线模式。
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
来源:https://www.jb51.net/database/32651707p.htm
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作! |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|
|
|
发表于 2024-9-11 15:12:42
来自手机
举报
回复
分享
|
|
|
|