幹壞事是進步最大的原動力
在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。
一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：
但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：
這樣看起來是個不錯的選擇...
在 Backend Tw 的 https://www.facebook.com/groups/616369245163622/posts/2467225396744655/ 這邊看到：
先大概回答一下假設，DELETE 後的空間是可以被同一個表格重複使用的，所以應該是還好，不過離峰時間跑一下 OPTIMIZE TABLE 也沒什麼關係就是了。
裡面提到的「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.7 文件) 以及「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.6 文件) 都有講到目前比較新的版本都已經是 Online DDL 了：(這邊抓 5.6 的文件，有支援的版本資訊)
Prior to Mysql 5.6.17, OPTIMIZE TABLE does not use online DDL. Consequently, concurrent DML (INSERT, UPDATE, DELETE) is not permitted on a table while OPTIMIZE TABLE is running, and secondary indexes are not created as efficiently.
As of MySQL 5.6.17, OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
文件上有提到會有一小段 lock 的時間，不過一般來說應該不會造成太大問題。
這邊要講的是早期的經典工具 pt-online-schema-change (pt-osc)，這是使用 TRIGGER-based 的方式在跑，他的範例就直接提供了一個不需要 Online DDL 支援的版本：
Change sakila.actor to InnoDB, effectively performing OPTIMIZE TABLE in a non-blocking fashion because it is already an InnoDB table:
pt-online-schema-change --alter "ENGINE=InnoDB" D=sakila,t=actor
這在早期的時候還蠻常被拿出來用的，如果還在維護一些舊系統的話還蠻推薦的...
前陣子的「為資料庫提案新的 UUID 格式」這邊提到了有人提案要增加新的 UUID 格式，Percona 的老大 Peter Zaitsev 在 Twitter 上貼了「UUIDs are Popular, but Bad for Performance — Let’s Discuss」這篇在 2019 年時他們家的文章，題到了 MySQL 使用 UUID 當作 Primary Key 的事情：
UUIDs are Popular, but Bad for Performance — Let’s Discuss
https://t.co/2ulSGPB77L— Peter Zaitsev (@PeterZaitsev) August 21, 2021
要注意的是這篇文章沒有要從頭解釋 UUID 對於 Primary Key 的壞處，如果你想要先了解的話，在這篇文章的開頭給了一堆其他文章的連結，裡面就有討論過了。
這篇主要是在討論，如果硬要用 UUID 當 Primary Key 時，可以有什麼方法降低對 InnoDB 的衝擊，剛好回應最近的提案。
開頭還是先花了一些篇幅大概講一下 UUID 的種類，然後在「What is so Wrong with UUID Values?」這邊提到了字串比較的差異，如果 UUID 是到最後一碼才不同的話 (這邊是跑 df878007-80da-11e9-93dd-00163e000002 與 df878007-80da-11e9-93dd-00163e000003 與比較一億次)：
1 row in set (27.67 sec)
但如果是一開始就不同的話 (這邊是選擇 df878007-80da-11e9-93dd-00163e000002 與 ef878007-80da-11e9-93dd-00163e000003) 會快很多：
1 row in set (2.45 sec)
但如果與數字相比的話 (這邊是 2=3 這樣的條件去比)：
1 row in set (0.96 sec)
可以看數字在這邊的優勢，另外也是在說明，如果你用的是 time-based ordering 的 UUID，要考慮會遇到這個可能會發生的效能問題。
再來是玩 UUID 的三種不同的儲存方式對於寫入效能的差異，分別是 CHAR(36) (32 bytes 的 hex 加上四個 -)、base64 (用 CHAR(22) 存) 與 BINARY(16)，可以看出來 BINARY(16) 因為佔用空間比較小的關係，是可以高速寫入持續最久的，再來是 base64，最差的是 CHAR(36)：
後面給了兩個 workaround，第一個算是定義了另外一種產生 128 bits 的方式，第二個則是想辦法把 UUID 對應到數字。
這在 MySQL 的環境裡面算是被討論的很久的主題了。(我猜在 PostgreSQL 應該也是，不過 PostgreSQL 的社群沒跟那麼久...)
Percona 的人寫了一篇關於 MySQL 跑在 AWS 上不同種類 EBS 的效能差異：「Performance of Various EBS Storage Types in AWS」，不過這篇的描述部份不是很專業，重點是直接看測試資料建立自己的理解。
他的方法是在 AWS 上建立了相同參數的 gp2、gp3、io1、io2 空間，都是 1TB 與 3000 IOPS，但他提到這應該會一樣：
So, all the volumes are 1TB with 3000 iops, so in theory, they are the same.
但這在「Amazon EBS volume types」文件上其實都有提過了，先不管 durability 的部份，光是與效能有關的規格就不一樣了。
在 gp2 的部份直接有提到只有保證 99% 的時間可以達到宣稱的效能：
AWS designs
gp2volumes to deliver their provisioned performance 99% of the time.
而 gp3 則是只用行銷宣稱「consistent baseline rate」，連 99% 都不保證：
These volumes deliver a consistent baseline rate of 3,000 IOPS and 125 MiB/s, included with the price of storage.
在 io* 的部份則是保證 99.9%：
Provisioned IOPS SSD volumes use a consistent IOPS rate, which you specify when you create the volume, and Amazon EBS delivers the provisioned performance 99.9 percent of the time.
另外在測試中 gp2 與 gp3 的 throughput 看起來也沒調整成一樣的數字。在 1TB 的 gp2 中會給 250MB/sec 的速度，1TB 的 gp3 則是給 125MB/sec，除非你有加買 throughput。
另外從這句也可以看出來他對 AWS 不熟：
The tests were only run in a single availability zone (eu-west-1a).
在「AZ IDs for your AWS resources」這邊有提過不同帳號之間，同樣代碼的 AZ 不一定是一樣的區域，需要看 AZ ID：
For example, the Availability Zone
us-east-1afor your AWS account might not have the same location asus-east-1afor another AWS account.
To identify the location of your resources relative to your accounts, you must use the AZ ID, which is a unique and consistent identifier for an Availability Zone. For example,
use1-az1is an AZ ID for theus-east-1Region and it is the same location in every AWS account.
在考慮到只有設定大小與 IOPS 的情況下，剩下的測試結果其實跟預期的差不多：io2 貴但是可以得到最好的效能，io1 的品質會差一些，gp3 在大多數的情況下其實很夠用，但要注意預設的 throughput 沒有 gp2 高。
Facebook Engineering 發了一篇將 MySQL 升級到 8.0 的說明：「Migrating Facebook to MySQL 8.0」。
先前的版本主要是 5.6，加上 MyRocks：
Our last major version upgrade, to MySQL 5.6, took more than a year to roll out. When version 5.7 was released, we were still in the midst of developing our LSM-Tree storage engine, MyRocks, on version 5.6. Since upgrading to 5.7 while simultaneously building a new storage engine would have significantly slowed the progress on MyRocks, we opted to stay with 5.6 until MyRocks was complete. MySQL 8.0 was announced as we were finishing the rollout of MyRocks to our user database (UDB) service tier.
在 GitHub 上是有 facebook/mysql-8.0，但看起來從 2017 後就沒更新了，所以應該是沒有 open source 出來。
看看就好 XD
Percona 的「MySQL/ZFS Performance Update」這篇又對 ZFS 做了一次測試，算是用比較新的軟體跑出來的結果，不過要注意這邊的 ZFS 版本仍然不是目前最新版：
ZFS 0.8.6-1 is not bleeding edge, there have been more than 1700 commits since and after 0.8.6, the ZFS release number jumped to 2.0. The big addition included in the 2.0 release is native encryption.
機器是在雲端上 (Azure 上)，不熟悉 Azure 的機種，但看記憶體與 CPU 的量好像不是用頂規的機器：
benchmark host
Standard D2ds_v4 instance
2 vCpu, 8GB of Ram and 75 GB of temporary storage
Debian BusterDatabase host
Standard E4-2ds-v4 instance
2 vCpu, 32GB of Ram and 150GB of temporary storage
256GB SSD Premium (SSD Premium LRS P15 – 1100 IOPS (3500 burst), 125 MB/s)
Debian Buster
Percona server 8.0.22-13
跑出來的結果看起來不差：
看了一下測試用的設定，似乎只測了 compression 的部份，沒測 snapshot 以及其他功能會對效能有什麼影響，但至少基本盤應該是還不錯？
在 Percona 的「How To Recover Percona XtraDB Cluster 5.7 Node Without SST」這邊看到的技巧，不過只能用在 5.7 版，不能用在 8.0 版。我猜這個方法也可以用在其他跑 Galera Cluster 的資料庫上...
維護一組 Percona XtraDB Cluster 時一個常見的問題是，當節點離線太久後有機會無法用 IST (Incremental State Transfer) 跟回來，也就是只要把先前還沒有同步的部份更新進資料庫的方法，這時候就會需要用 SST (State Snapshot Transfer)，變成抓整個 full copy。
作者提出來的方法是基於 IST 的大小通常比較小，但 binlog 通常都留蠻久的，所以可以利用 binlog 來幫 IST。
方法是先把 Galara Cluster 關掉，用 MySQL 傳統的 replication 同步到一定程度後，再把 IST 相關的位置設定指到已經同步的位置，接著再把 Galara Cluster 接上去就可以恢復了。
這個方法是 5.7 版限定，因為 8.0 的年代沒辦法改 Galara Cluster 的 wsrep 位置資訊：
Unfortunately, a similar solution does not work with Percona XtraDB Cluster 8.0.x, due to the modified way wsrep positions are kept in the storage engine, hence the trick with updating grastate.dat does not work as expected there.
我覺得可能 Percona 之後會弄出 patch 讓使用者可以改...
看到「Dolt is Git for Data!」這個專案，是個在本機上跑的 MySQL server，另外可以在上面的資料進行版本控制，看起來很適合本機開發測試。
首先抓下來可以看到沒幾個檔案 (這是 linux-amd64 版)，也可以看到跟 Git 的關係：
$ tree . ├── bin │ ├── dolt │ ├── git-dolt │ └── git-dolt-smudge └── LICENSES
然後用 bin/dolt sql-server -P 3307 -u root -p passw0rd 跑就可以把一個相容於 MySQL 的伺服器跑在 port 3307，然後用 mysql -h 127.0.0.1 --port 3307 -u root -p 就可以輸入密碼 passw0rd 登入進去：
$ mysql -h 127.0.0.1 --port 3307 -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.7.9-Vitess
可以從 Server version 看到專案是用了 Vitess 實做的 MySQL 界面。
另外測了一下，透過連線所做的變更 (像是 CREATE DATABASE 與 CREATE TABLE，以及 CRUD 中的 CUD) 是不會寫回磁碟裡的，嘗試了不同的設定，不管改什麼都是這樣，應該是故意設計成這樣。
在本機跑 test case 測試應該還不錯，會比 SQLite 的 :memory: 更接近 MySQL 一些，不過在 CI 裡的話應該是可以直接把 MySQL 跑起來...
在 2021 年看到 Eventbite 的 MySQL 升級計畫：「MySQL High Availability at Eventbrite」。
看起來是 2019 年年初的時候 MySQL 5.1 出問題，後續決定安排升級，在 2019 年年中把系統升級到 MySQL 5.7 (Percona Server 版本)：
Our first major hurdle was to get current with our version of MySQL. In July, 2019 we completed the MySQL 5.1 to MySQL 5.7 (v5.7.19-17-log Percona Server to be precise) upgrade across all MySQL instances.
然後看起來是直接在 EC2 上跑，不過這邊提到的空間問題就不太確定了，是真的把 EBS 的空間上限用完嗎？比較常使用的 gp2 與 gp3 上限都是 16TB，不確定是不是真的用到接近爆掉了：
Not only was support for MySQL 5.1 at End-of-Life (more than 5 years ago) but our MySQL 5.1 instances on EC2/AWS had limited storage and we were scheduled to run out of space at the end of July. Our backs were up against the wall and we had to deliver!
另外在升級到 5.7 的時候，順便把本來是 INT 的 primary key 都換成 BIGINT：
As part of the cut-over to MySQL 5.7, we also took the opportunity to bake in a number of improvements. We converted all primary key columns from INT to BIGINT to prevent hitting MAX value.
然後系統因為舊版的 Django 沒辦法配合 MySQL 5.7，得升級到 Django 1.6 (要注意 Django 1 系列的最新版是 1.11，看起來光是升級到 1.6 勉強會動就升不上去了？)：
In parallel with the MySQL 5.7 upgrade we also Upgraded Django to 1.6 due a behavioral change in MySQL 5.7 related to how transactions/commits were handled for SELECT statements. This behavior change was resulting in errors with older version of Python/Django running on MySQL 5.7
然後採用了 GitHub 家研發的 gh-ost 當作改變 schema 的工具：
In December 2019, the Eventbrite DBRE successfully implemented a table ALTER via gh-ost on one of our larger MySQL tables.
看起來主要的原因是有遇到 pt-online-schema-change 的限制 (在「GitHub 發展出來的 ALTER TABLE 方式」這邊有提到)：
Eventbrite had traditionally used pt-online-schema-change (pt-osc) to ALTER MySQL tables in production. pt-osc uses MySQL triggers to move data from the original to the “duplicate” table which is a very expensive operation and can cause replication lag. Matter of fact, it had directly resulted in several outages in H1 of 2019 due to replication lag or breakage.
另外一個引入的技術是 Orchestrator，看起來是先跟 HAProxy 搭配，不過他們打算要再換到 ProxySQL：
Next on the list was implementing improvements to MySQL high availability and automatic failover using Orchestrator. In February of 2020 we implemented a new HAProxy layer in front of all DB clusters and we released Orchestrator to production!
Orchestrator can successfully detect the primary failure and promote a new primary. The goal was to implement Orchestrator with HAProxy first and then eventually move to Orchestrator with ProxySQL.
然後最後題到了 Square 研發的 Shift，把 gh-ost 包裝起來變成有個 web UI 可以操作：
2021 還可以看到這類文章還蠻有趣的...