這陣子在處理 MySQL 5.6 -> 5.7 -> 8.0 升級的事,踩到一些地雷;紀錄一下。
目前新版的 MySQL 5.7 & 8.0 在全新安裝時會隨機產生 root 的密碼,並把密碼寫在 log 裡面。
這行為在自動化佈署時會遇上點麻煩,而避免隨機產生 root 密碼的方式是在 script 作這樣的事:
...
mysqld --initialize-insecure
systemctl start mysqld
echo "ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' BY '##########';" | mysql
...
(5.7 -> 8.0)升級方面,第一個變化是 mysql_upgrade 不需要執行了;server 在啟動時會檢查,並自行升版。
原本在 5.7 版仍能使用的幾個 Server System Variables 在 8.0 版必須移除:
- query_cache_type = 0
- query_cache_size = 0
- innodb_large_prefix = 1
- innodb_file_format = Barracuda
expire_logs_days 也應移除,改用 binlog_expire_logs_seconds。
我另外在 8.0 版補上這兩個設定:
- mysqlx = 0
- default_authentication_plugin = mysql_native_password
5.7 -> 8.0 的預設語系/字元集有變化:
| character_set_server | collation_server |
MySQL 5.7 | latin1 | latin1_swedish_ci |
MySQL 8.0 | utf8mb4 | utf8mb4_0900_ai_ci |
特別提 8.0.20 是因為使用 Percona XtraBackup 時踩到地雷(Ref. percona-xtrabackup-80 does not work with mysql 8.0.20);原因是 Redo log 格式被更改了,Changes in MySQL 8.0.20 (2020-04-27, General Availability) 裡面有這段:
InnoDB: Redo log records for modifications to undo tablespaces increased in size in MySQL 8.0 due to a change in undo tablespace ID values, which required additional bytes. The change in redo log record size caused a performance regression in workloads with heavy write I/O. To address this issue, the redo log format was modified to reduce redo log record size for modifications to undo tablespaces. (Bug #29536710)
(有興趣深究的可以看看這個 commit)
Percona XtraBackup – Documentation 裡面也有這段說明:
Due to changes in MySQL 8.0.20 released by Oracle at the end of April 2020, Percona XtraBackup 8.0, up to version 8.0.11, is not compatible with MySQL version 8.0.20 or higher, or Percona products that are based on it: Percona Server for MySQL and Percona XtraDB Cluster.
另外一顆地雷是 Drupal 7 在連線初始化時會設定 SQL mode,但 NO_AUTO_CREATE_USER 在 8.0 被拿掉了;目前先用 這個 comment 裡面夾帶的 patch 作修正。
11 月 29 2020
測試 Raspberry Pi 4 可用的 storage devices
數年前我開始玩 Raspberry Pi ,第一款入手的是 Raspberry Pi 2 model B;原先的想法是在家弄個微型 Linux server,運氣好的話還能裝 desktop 版,接上電視當 Thin client。
但這個版本 CPU 速度不快,記憶體不大,MicroSD 的 file I/O 也不算快,我裝起來玩沒幾個月就撤下來了…
之後我在看到 Orange Pi 的 benchmarking 文章,感覺內建的 EMMC 速度不錯,就買了一台 Orange Pi Plus 2 來玩。
也是玩沒幾個月,發現 Orange Pi 的生態系不太完整,而且 Orange Pi Plus 2 的 CPU 發熱量頗高,非得搞個風扇才能讓它保持清醒(風扇還要定時更換),便又把它撤下來了…
Raspberry Pi 4 大概是在 2019 年六月面世,而且 Benchmarking the Raspberry Pi 4 這文有一部份對我挺有吸引力…
我想在家弄的 Linux server 已經被我扔進 NAS 的 VM,直到 8GB 記憶體的版本面世,我才又入手。
把它裝起來玩之後,發現 MicroSD 的 file I/O 依舊無法跟 NAS 裡面的 VM guest 相比,便又擱著…
直到最近看到一堆 Raspberry Pi 4 的 USB boot 文,才又有動力把它抓出來測 file I/O ,順便留個紀錄。
在測試前,有件事讓我搞很久…
我用 USB 外接硬碟可以作 USB boot,但用 Intel SSD 760p 配 Asus ROG STRIX ARION、伽利略 M2NVU31(晶片是 JMS583)一直失敗…
我在 Facebook 的台灣樹苺派社群提問,便有人回覆提醒我該注意供電與轉接器的主控晶片。
於是我把裝置接上一個可額外供電的 USB 3.0 hub,NVMe SSD 搭配 JMS583 主控 就成功達成 USB boot 了…
隨後又在網路上找了個 RTL9210 主控的轉接器,發現 RTL9210 毋需額外供電,直接接上就可以作 USB boot。
測試的配置圖(開機時僅接上 NVMe SSD):
Raspberry Pi 4 的一些基本資訊,開機後裝上 & 掛載受測的 storage devices:
fio 的參數都一樣:
前面的廢話夠多了,先列 fio 的隨機存取測試結果;由快到慢分別是:
有興趣的可以繼續看測試截圖…
More
By Joe Horn • Computer Hardware 1 • Tags: benchmarking, fio, JMS583, MicroSD, NVMe SSD, Orange Pi, Raspberry Pi, Raspberry Pi 4, RTL9210, SATA SSD, TFcard, USB flash, USB HDD