6 月 8 2021
之前寫 MySQL 8.0.23 released 是 1 月的事，但 Percona XtraBackup 在兩個月後（3 月）才釋出 8.0.23-16.0；接著 MySQL 在 2021-04-20 釋出 8.0.24，2021-05-11 釋出 8.0.25 ，所以 Percona XtraBackup 的版本編號就直接跳上 8.0.25-17.0 了…
這個版本比較特別的是權限調整，需要額外賦予 performance_schema.keyring_component_status 這個 TABLE 的 SELECT 權限，如下圖標示處。
（參照：Percona XtraBackup – Documentation : Connection and Privileges Needed）
P.S. 在 Github 也可以看到紀錄： PXB-2490 xtrabackup privileges update (8.0)
1 月 19 2021
剛看到 MySQL 8.0.23 的 release note ，便挑了台機器試試。
先談測試結果：建議 PXB（Percona XtraBackup） 的使用者先等待新版釋出再一併作升版。
原因如下：
2020 年資訊/軟體界在談論 master / slave 與 blacklist / whitelist 這類可被聯想成「歧視」的字眼，而 MySQL 也開始作調整了…
8.0.22 版開始調整 “SLAVE” 字眼（Ref. MySQL 8.0.22 的 release note）：
新釋出的 8.0.23 調整 “MASTER” 與 “blacklist” 字眼：
另外，參照這頁，MySQL 8.0.23 的資料庫帳號 host 欄位開始支援 CIDR 格式。
12 月 14 2020
這篇也算是作紀錄。
Percona 在 2020-10-23 貼出這文： MySQL New Releases and Percona XtraBackup Incompatibilities；裡面這段看起來感覺像是又被搞了…
特別強調 “又” 字是因為已經有過一次，而且放在 Percona XtraBackup – Documentation，但這次只張貼 blog post，沒寫在文件…
恰巧某台 11 月初新裝的 Linux 踩到坑，便持續關注 Percona XtraBackup 等新版釋出。
幾天前發現 Percona XtraBackup 的 github 有這個 pull request：PXB-2373 Release Notes for 8.0.22-15.0 (8.0)，今天就在下載頁看到了（而且換了版本編號邏輯… 
）
雖然 Percona XtraBackup 8.0 Release Notes 尚未更新，但剛測試的確沒看到 unknown error …
另外，MySQL 8.0.22 還有這變革…
12 月 10 2020
這是這幾天作過簡單的實驗，實驗完畢馬上在正式環境完成的事，寫個文章作紀錄。
LVM （Logical Volume Manager） 不是新穎的技術，搭配 mdadm、iSCSI、DRBD 可以搞出不少花樣。
情境是 server 掛載 A 廠牌 storage server 的 iSCSI target 作為資料與程式的儲存點，而這些資料要搬移到 B 廠牌 storage server 的 iSCSI target；而這台 server 用 LVM 把 iSCSI target 製作成 PV （Physical Volume），並建立好 VG （Volume Group）與 LV （Logical Volume），掛載 LV 儲存資料。
變數說明：
步驟如下：
# iscsiadm -m session # iscsiadm -m node
# iscsiadm -m discovery -t st -p [portal_B] # iscsiadm -m node -T [target_B] -p [portal_B] --login
# pvcreate /dev/sdb
# vgextend VolGroup /dev/sdb
# pvmove /dev/sda /dev/sdb
# vgreduce VolGroup /dev/sda
# pvremove /dev/sda
# iscsiadm -m node -T [target_A] -p [portal_A] --logout # iscsiadm -m node -T [target_A] -p [portal_A] -o delete
收工。
一旦 iSCSI node 確認是乾淨的，目前的 /dev/sdb 在重新開機後會成為 /dev/sda，且 LVM 會辨識出這個 PV，並放進 VG；而這整段流程毋需對 LV 作 umount & mount，服務也毋需暫停/中斷（LVM 的 device mapper 會幫我們顧好… 
）。
12 月 7 2020
之前測過 Raspberry Pi 4 可用的 storage devices ；讓我選擇的話，不在 Raspberry Pi 4 透過 USB 3 裝 SSD，大概就是 MicroSD card 。
fio 只能測試 file I/O，而 sysbench 可以測試 CPU 跟 memory，甚至還能測試 DBMS 效能。
測試基準作業系統都是 Ubuntu 20.10，安裝 MySQL 8，使用的工具是 sysbench ，用 oltp_read_write 作測試。（Percona 尚未提供 groovy 的 repository，就先不用 sysbench-tpcc 作測試了…）
裝機之後簡單執行這幾行指令：
# mysql -e "CREATE DATABASE sbtest;" # sysbench oltp_read_write --mysql-user=root prepare # sysbench oltp_read_write --mysql-user=root run
Intel SSD 760p 搭配 NVMe-to-USB3 轉接器，fio 測得結果是 iops 約 11k，傳輸約 42MB/s 。
SanDisk Extreme Pro MicroSD card，fio 測得結果是 iops 約 390，傳輸約 1560KB/s 。
對照組，這是在 DigitalOcean 開 US$ 10/mo 的 VPS （1 vCPU & 2GB RAM）作測試。
（看 /proc/cpuinfo 是 Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.30GHz ，bogomips 約 4k）
有想要放網站的話，選用 VPS 還是會比較好… 至少，被攻擊的時候不會塞滿自己的頻寬。
有興趣玩 VPS 的可以參考這裡呀…
11 月 29 2020
數年前我開始玩 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 的參數都一樣：
-iodepth=128 -ioengine=libaio -bs=4k \ --runtime=300 --size=500M \ --direct=1 --rw=randrw
前面的廢話夠多了，先列 fio 的隨機存取測試結果；由快到慢分別是：
有興趣的可以繼續看測試截圖…
More
11 月 15 2020
我原本使用 dehydrated，前陣子開始改用 certbot。
對我這懶人來說，certbot 有 rpm & dpkg，也都有 yum 跟 apt 的 repositories 可用，這點挺重要…
單機（純 hostname）的 certificate 搭配 nginx 用這行指令就可以完成：
certbot certonly --nginx -d {hostname}取用 wildcard certificate 的話可以先看看 certbot 的 DNS Plugins 文件。
我自己的網域 DNS server 是自己掌管的，搭配的是 certbot-dns-rfc2136 。
編輯完設定檔（eg. /etc/letsencrypt/rfc2136.ini）之後也是一行指令完成：
certbot certonly \
--dns-rfc2136 \
--dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini \
-d *.{DOMAIN} -d {DOMAIN}
另外，在 Ubuntu 安裝的 certbot 已經使用 systemd 的 timers 觸發定時更新，用下面這行指令可以確認其狀況。
systemctl status certbot.timer
7 月 31 2020
續前一篇，這陣子除了表訂工作之外，就是觀察 MySQL 升級後有哪些地雷被引爆，接著開始救傷。
一顆跟 Java/JDBC 有關，錯誤訊息如下圖；原因是 MySQL 8 沒有 query_cache_size 等等的參數，而解決方式是更新 MySQL Connector/J。
另外一顆的成因/故事就比較長了…
MySQL 8 之前的版本，我們習慣把 character_set_server 設為 utf8 ，而 collation_server 設為 utf8_general_ci ；升版前看到這兩個變數預設值都換掉了，就很開心的拿掉… 於是部份（年紀比較大）的 PHP web server 就爆了，錯誤訊息如下圖。
初步研判以為是 PHP 認不得 utf8mb4 ，仔細追查後發現真因是「認不得 utf8mb4_0900_ai_ci」，解決方式是把 collation_server 設為 utf8mb4_general_ci 。
附帶一提， PHP 5.3 的 ext/mysqlnd 沒這問題，僅 5.4 ~ 5.6 受影響，而 PHP 7 之後都支援 UCA Ver.9 的 collations …
8 月 7 2021
Oracle Cloud Free Tier
前陣子看到 Oracle Cloud Free Tier ，網頁說下圖這些服務是永遠免費的，便註冊了一個帳號試玩看看…
參閱這個頁面的說明之後，我建立了一個 Compute VM instance 跟一塊 Block Storage 作些簡單的測試。
免費的服務當然有些代價，與其他 VPS 付費建立的 instance 相比，差別最大的是 Disk I/O；Oracle Cloud Free Tier 提供的硬體應該是 HDD，不是 SSD。
這圖是 Oracle Cloud Free Tier 的 sysbench 測試結果：
Vultr 的付費 VM instance 配置 SSD ，測試結果如下：
感覺 Oracle Cloud Free Tier 的永遠免費資源在學習、測試的用途上是足夠的，但架設網站應該是不太行。
我個人是把 Compute VM instance 用作 MySQL replica，並掛載 Block Storage 作為 MySQL 的資料目錄，定時作 btrfs snapshot。
分享此文：
By Joe Horn • Linux 0 • Tags: Free Tier, Oracle Cloud, VPS