MySQL8.4設置密碼規(guī)則為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) 查看插件狀態(tài)

show plugins;

看看mysql_native_password插件的狀態(tài)是不是ACTIVE,如果狀態(tài)值為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.一些系統(tǒng)變量默認值變更

MySQL 8.4，還調整了與 InnoDB 存儲引擎相關的多個服務器系統(tǒng)變量的默認值，比如：

innodb_io_capacity

• 默認值改成了10000，之前是200。
• 控制每秒可用于 InnoDB 后臺任務的 I/O 數。
• 比如緩沖池中的頁面刷新，或者合并來自更改緩沖區(qū)的數據。
• 如果是 SSD，可設置 5000 以上。
• 現在線上MySQL，基本都是SSD，所以默認值設置成10000也合理。

innodb_buffer_pool_instances

• InnoDB 緩沖池的區(qū)域數，將緩沖池劃分多個區(qū)域，可以減少不同線程讀取和寫入緩存頁時的爭用，可提高并發(fā)性。
• 之前默認值是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。

innodb_change_buffering

• 決定哪些操作會使用change buffer，有關change buffer，我們在前面詳細介紹過：一文弄懂MySQL更改緩沖區(qū)。
• 之前的版本默認值是all，表示innodb_change_buffering會緩存插入、刪除標記操作和后臺發(fā)生的物理刪除操作。
• 從8.4開始，默認是none，表示不緩存這些修改操作，這個不太理解，大家可以在留言區(qū)討論，可能考慮什么因素。

3.克隆插件

克隆插件的版本要求放寬，允許在同一大版本號下的不同小版本之間進行克隆。

4.組復制相關

group_replication_set_as_primary變化

使用group_replication_set_as_primary() 選舉新主節(jié)點前，會等待正在進行的 DDL 語句完成。當然，這個是從8.1開始有的特性。

參數group_replication_consistency默認值變更

默認值改成了BEFORE_ON_PRIMARY_FAILOVER，以前是EVENTUAL。

這里補充一下group_replication_consistency幾個值的介紹：

• EVENTUAL：事務提交后會廣播到集群的多數節(jié)點，然后節(jié)點檢查是否有沖突，如果沒有沖突，則事務在本地提交，其他節(jié)點異步處理，可能導致讀取到稍舊的數據。
• BEFORE_ON_PRIMARY_FAILOVER：在主節(jié)點故障時，必須等待新主處理完待處理的事務，才能開始響應業(yè)務的讀寫請求，這樣可以保證業(yè)務讀寫請求不會讀取到舊數據。
• BEFORE：一個事務會等待之前的事務執(zhí)行完后再開始執(zhí)行，確保讀取到的數據是最新的。
• AFTER：寫事務會等待其更改在所有其他節(jié)點應用后才提交，保證后續(xù)事務讀取已寫入或其他節(jié)點上最新的值。對只讀事務沒有影響
• BEFORE_AND_AFTER：會等待之前的事務執(zhí)行完后才開始執(zhí)行新事物，并等到事務在所有節(jié)點應用后才提交，確保讀取和提交都具有強一致性。

參數group_replication_exit_state_action默認值變更

group_replication_exit_state_action 默認值改成了OFFLINE_MODE，以前是READ_ONLY。

這個參數控制了MGR實例處理故障節(jié)點的方式，有三個選項：

• 設置為read_only時，會把這個實例的super_read_only設置為on；
• 設置為offline_mode時，會把這個實例切換到離線模式
• 設置為abort_server時，將關閉MySQL。

我們可以回顧一下MGR的故障檢測流程：

也就是當一個節(jié)點出現故障之后，進行group_replication_autorejoin_tries參數配置的自動重連次數之后。

這個節(jié)點的行為，之前默認情況下，是設置為super_read_only，現在是會把實例切換到離線模式。

總結

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論