算了一下成本還可以接受 (機器 + 空間 + 流量)，就把 blog 搬到 AWS 的 t4g.small (ARM) 上，理論上頁面的速度應該會快不少，過幾天等穩定性沒問題後就來買 RI...
從 x86-64 轉到 ARM 上面，主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository，所以就改用 MariaDB 了。
Tag: percona
Eventbrite 的 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 還可以看到這類文章還蠻有趣的...
產生名次的 SQL
在 Percona 的「Generating Numeric Sequences in MySQL」這篇在討論產生字串序列，主要是在 MySQL 環境下，裡面看到的技巧「Session Variable Increment Within a SELECT」這組，剛好可以用在要在每個 row 裡面增加名次：
SELECT (@val := @val + 1) - 1 AS value FROM t1, (SELECT @val := 0) AS tt;
另外看到 MariaDB 與 MySQL 8.0 系列因為有多支援各種功能，剛好也可以被拿來用，然後最後也提到了 Percona 自家出的 MySQL 8.0.20-11 將會直接有 SEQUENCE_TABLE() 可以用 (這應該才是 Percona 這篇文章的主要目的，推銷一下自家產品的新功能)。
文章收起來之後遇到可以拿出來參考用...
Percona 對 MongoDB 的建議
看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇，裡面給了五個建議，其中第五點頗有趣：
5) Whenever Possible, Working Set < RAM
As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.
這樣的設計邏輯很奇怪啊，你不要扯其他 database 啊，你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊，反過來才是用 InnoDB 的常態吧，而且在 PostgreSQL 上也是這樣吧 XDDD
現在上面的文章真的是挑著看了... XD
MariaDB 的 S3 Engine 效能測試
Percona 對 MariaDB 在 10.5 (目前的最新穩定版) 裡出的 S3 Engine 給出了簡單的測試報告：「MariaDB S3 Engine: Implementation and Benchmarking」。
這個 engine 顧名思義就是把資料丟到 Amazon S3 上，目前是 alpha 版本，預設是不會載入的，需要開 alpha flag 才能用：
The S3 engine is READ_ONLY so you can’t perform any write operations ( INSERT/UPDATE/DELETE ), but you can change the table structure.
另外這是從 Aria 改出來的 read-only engine，而 Aria 是從 MyISAM 改出來的：
The S3 storage engine is based on the Aria code and the main feature is that you can directly move your table from a local device to S3 using ALTER.
測出來發現在 read-only 的情境下，COUNT(*) 超快，看起來就是跟 MyISAM 體系有關，直接撈 MyISAM 內的資料，所以本地要 18 秒，但放到 S3 反而秒殺 XDDD
整體看起來還不錯？算是一種 Data warehouse 的方案，主要是要用到 row-based format 儲存的優點，遇到一些冷資料可以這樣玩。
從「Using the S3 Storage Engine」這邊的設定方式看到 s3_host_name，看起來有機會接其他家的 S3 API，或是本地的 Storage。
話說 Aria 這個引擎當初最主要的重點就在 crash-safe，在有了 crash-safe 之後，DRBD 這種 block-level replication 機制就可以硬幹上去，後來主力就在擴充其他型態了，像是 GIS 與 virtual column 的功能，不過這些功能本家在 InnoDB 上好像也都陸陸續續跟上來了，單純的 Aria engine 好像還好...
Multithreading 版本 pt-online-schema-change
看起來是個嘗試，Percona 的人試著修改 pt-online-schema-change，讓他可以在 INSERT 時 multi-threading，然後看效果：「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。
可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字，下圖是看相對比率)：
如果沒有意外的話應該會有更多的測試，而這些測試沒問題的話，之後的官方版本裡面應該就會有這個功能。
在網路流量很大時，Container 的網路對資料庫效能的影響
在 Percona 的「How Container Networking Affects Database Performance」這篇在討論 Kubernetes 上選擇不同的 CNI 對於資料庫效能的影響。
最重要的是結果的這張圖：
可以看到 TPS 與 throughput 都有影響到，要注意的是這是兩個不同的工具測出來的結果，在 TPS 上是用 sysbench，可以看到最好的 Kube-Router 上也掉了 13% 的 TPS：
Another key thing we found was that even in the best-case with Kube-Router we see an approximate 13% decrease in database performance comparing bare metal to running within Kubernetes. This illustrates that there are still improvements to be made to the performance of container networking in Kubernetes.
throughput 是用 iperf3，只要不是真的掉很多，就沒那麼關心了...
不過這個測試另外一個解讀是，如果你用資料庫不單純是 PK find() 類的處理，那麼效能應該是還好，因為會有不少 CPU 資源 (以及對應的時間) 是用在 join 或是其他處理上，對於 latency 與 throughput 應該就沒有那麼敏感了...
sysbench 的 RNG
在 Percona 的 blog 上看到了 sysbench 的 RNG (Random Number Generator) 跟想像中的不太一樣：「What You May Not Know About Random Number Generation in Sysbench」。
預設是 Special：
而不是直覺的 Uniform (也有提供)：
另外還提供三種：
翻了翻可以翻到其他四個的理論基礎，但就是不知道 Special 的設計理論在哪裡...
MySQL (InnoDB) 的內部狀態
Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題，不過裡面也提到了不少有用的指令，平常可以先熟悉一下輸出，等真的有狀況的時候才會想起來可以用這些指令。
首先是最經典的 SHOW ENGINE INNODB STATUS，算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況，藉以猜測內部現在是怎麼卡住...
另外一個是 SHOW ENGINE INNODB MUTEX，就如同 Peter Zaitsev 所提到的，這個指令想辦法抓出最重要的資訊，但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。
另外當然就是 INFORMATION_SCHEMA，他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去，這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)
在 SQL 裡面避免大量刪除資料的方式
看到 Percona 的「An Overview of Sharding in PostgreSQL and How it Relates to MongoDB’s」這篇，雖然是在講 PostgreSQL 上的 sharding (以及 partition)，突然想到好像沒寫過要怎麼避免大量刪除資料的操作...
一個常見的情境是，想要讓某個表格只保留這一個月的資料，所以每個月開頭都會跑一隻 cron job 負責刪掉上個月的資料，像是 DELETE FROM xxx WHERE timestamp < yyy; 這樣的指令。
這個方式無論是在 PostgreSQL 或是 MySQL 都需要很多時間與 I/O 資源，而透過 partition 將不同時間區段切開到不同的表格，再用 TRUNCATE 直接清空表格剛好可以解這樣的問題。
Percona 的文章裡說了一些 PostgreSQL 的歷史與目前的進展。
在 PostgreSQL 9 或更早以前的版本，一個常見的作法是透過 table inheritance 實做 partition，然後用再用 function 實做 INSERT：
CREATE TABLE temperature (
id BIGSERIAL PRIMARY KEY NOT NULL,
city_id INT NOT NULL,
timestamp TIMESTAMP NOT NULL,
temp DECIMAL(5,2) NOT NULL
);
CREATE TABLE temperature_201901 (CHECK (timestamp >= DATE '2019-01-01' AND timestamp <= DATE '2019-01-31')) INHERITS (temperature);
CREATE TABLE temperature_201902 (CHECK (timestamp >= DATE '2019-02-01' AND timestamp <= DATE '2019-02-28')) INHERITS (temperature);
CREATE TABLE temperature_201903 (CHECK (timestamp >= DATE '2019-03-01' AND timestamp <= DATE '2019-03-31')) INHERITS (temperature);
CREATE OR REPLACE FUNCTION temperature_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.timestamp >= DATE '2019-01-01' AND NEW.timestamp <= DATE '2019-01-31' ) THEN INSERT INTO temperature_201901 VALUES (NEW.*);
ELSIF ( NEW.timestamp >= DATE '2019-02-01' AND NEW.timestamp <= DATE '2019-02-28' ) THEN INSERT INTO temperature_201902 VALUES (NEW.*);
ELSIF ( NEW.timestamp >= DATE '2019-03-01' AND NEW.timestamp <= DATE '2019-03-31' ) THEN INSERT INTO temperature_201903 VALUES (NEW.*);
ELSE RAISE EXCEPTION 'Date out of range!';
END IF;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
在 PostgreSQL 10 之後，就直接支援一些與 partition 相關的設計，像是這樣：
CREATE TABLE temperature (
id BIGSERIAL NOT NULL,
city_id INT NOT NULL,
timestamp TIMESTAMP NOT NULL,
temp DECIMAL(5,2) NOT NULL
) PARTITION BY RANGE (timestamp);
CREATE TABLE temperature_201901 PARTITION OF temperature FOR VALUES FROM ('2019-01-01') TO ('2019-02-01');
CREATE TABLE temperature_201902 PARTITION OF temperature FOR VALUES FROM ('2019-02-01') TO ('2019-03-01');
CREATE TABLE temperature_201903 PARTITION OF temperature FOR VALUES FROM ('2019-03-01') TO ('2019-04-01');
雖然還是有些限制，但可以看出比起以前簡單不少。
而有了 partition 後，文章的後續就在討論這跟 MongoDB 的 sharding 有什麼關係，但這就不是我關注的事情了...