Tag: mysql

這個月 GitHub 的不穩問題，都是 mysql1 這個 cluster 的鍋...

GitHub 針對了這個月的四次 downtime 說明，大致上都跟 mysql1 這組 cluster 有關：「An update on recent service disruptions」，這是 Keith Ballinger 發的文章，找了一下掛的頭銜是 SVP of Engineering at GitHub。

文章裡提到的 mysql1 在「Partitioning GitHub’s relational databases to handle scale」這邊可以看到一些資訊 (我在「GitHub 的 MySQL 架構與數字」這邊也有提到)，基本上有 ProxySQL + Vitess 兩套方案在 scale，但可以看出來主資料庫本身還是有很大的 loading 在上面跑。

這次的問題是 mysql1 看起來這次遇到了效能上的瓶頸，不過還是沒找到原因，這可以從這幾次的說明看出來，從第一次的 outage：

The incident appeared to be related to peak load combined with poor query performance for specific sets of circumstances.

第二次的：

The following day, we saw the same peak traffic pattern and load on mysql1. We were not able to pinpoint and address the query performance issues before this peak, and we decided to proactively failover before the issue escalated.

第三次的：

While we had reduced load seen in the previous incidents, we were not fully confident in the mitigations.

In this third incident, we enabled memory profiling on our database proxy in order to look more closely at the performance characteristics during peak load.

到最近第四次的：

In order to reduce load, we throttled webhook traffic and will continue to use that as a mitigation to prevent future recurrence during peak load times as we continue to investigate further mitigations.

可以看到基本上還沒完，之後再遇到問題時應該還是會把 webhook traffic 拿出來開刀...

Linode 過了三年，終於想起來要推出 Managed Databases 服務了

看到 Linode 宣佈 Managed Databases 服務：「Linode Managed Databases in Open Beta」。

測試期間不用錢，但目前只有支援 MySQL，其他幾個像是 PostgreSQL、Redis 與 MongoDB 都還沒推出 (在 roadmap 上)：

Our new managed database service is now in open beta for new and existing customers! We currently support MySQL during this beta—with a near-term roadmap to add PostgreSQL, Redis, MongoDB—and plan to include additional features.

搜了一下隔壁 DigitalOcean 的資料，Manage Databases 這條產品線在 2019 年二月推出 PostgreSQL 的版本：「Our Valentine’s Gift to You: Managed Databases for PostgreSQL」，在 2019 年八月推出了 MySQL 與 Redis 的版本：「Take the worry out of managing your MySQL & Redis databases」，然後在 2021 年六月推出了 MongoDB 的版本：「Introducing DigitalOcean Managed MongoDB – a fully managed, database as a service for modern apps」。

不過 Vultr 看起來是還是完全沒有樣子，相比起來 Linode 好像不算慢？

另外看起來 DigitalOcean 是跟 MongoDB 合作，不像 AWS 自己另外用 PostgreSQL 搞了一套 XDDD

MariaDB Corporation Ab 透過 SPAC 上市

MariaDB Corporation Ab 透過 SPAC 上市：「MariaDB Corporation Ab to Become a Publicly Traded Company via Combination with Angel Pond Holdings Corporation」。

Upon closing of the transaction, the combined company will be named MariaDB plc and led by MariaDB’s CEO Michael Howard.

Hacker News 上有一些對 MariaDB 的討論可以看一下 (是對軟體討論，不是對公司討論)：「MariaDB to go public at $672M valuation (mariadb.com)」。

大多數用 MariaDB 的人其實都只是在用 MySQL 的功能，不常用到 MariaDB 的特殊功能，像是 Aria (MyISAM 的 crash-safe 版本) 還是沒有 transaction，而 InnoDB 的效能其實相當好，就找不太到理由去用 Aria...

另外從 Google Trends 的 volume 也可以看出來趨勢是往下降而非向上爬升，這時候趕快脫手 (而且還是透過 SPAC) 看起來是最好的時機？

Amazon RDS 支援 readonly instance 當作 Multi AZ 的機器了

從來沒在用 RDS 的 Multi AZ，所以根本沒注意到居然沒這個功能：「New Multi-AZ deployment option for Amazon RDS for PostgreSQL and for MySQL; increased read capacity, lower and more consistent write transaction latency, and shorter failover time (Preview)」。

看起來 (加上印象中) 之前的 Multi AZ 是另外一台機器先開著但不能用：

In the case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby, so that database operations resume as soon as the failover is complete.

現在則是開著的機器可以跑 readonly 模式：

The standby DB instances act as automatic failover targets and can also serve read traffic to increase throughput without needing to attach additional read replica DB instances.

這樣做除了省成本外，另外因為這些 instance 平常就有 query 的量，當真的遇到 failover 切換時，warmup 的時間也會短很多 (尤其是服務夠大的時候)。

不過有些限制，首先看起來只支援 Graviton2 (ARM-based) 的機種？

The readable standby option for Amazon RDS Multi-AZ deployments works with AWS Graviton2 R6gd and M6gd DB instances (with NVMe-based SSD instance storage) and Provisioned IOPS Database Storage.

然後是支援的區域：

The Preview is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions.

以及夠新的版本，MySQL 8 與 PostgreSQL 13.4 才有提供：

Amazon RDS for MySQL supports the Multi-AZ readable standby option for MySQL version 8.0.26. Amazon RDS for PostgreSQL supports the Multi-AZ readable standby option for PostgreSQL version 13.4.

但看起來還不錯，畢竟這比較接近以前在地端機房時的作法...

用 PostgreSQL 的 int4range 與 GiST

發現自己根本還不熟悉 PostgreSQL 的特性，寫一下記錄起來。

產品上常常會有 coupon 與 voucher 之類的設計，這時候通常都會設定 coupon 或 voucher 的有效期間，在 MySQL 的環境下可能會這樣設計：

CREATE TABLE coupon (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(255) NOT NULL,
  started_at INT UNSIGNED NOT NULL,
  ended_at INT UNSIGNED NOT NULL
);

另外是設計 index 的部份，在產品推出夠久後，通常是過期的 coupon 或 voucher 會比目前還有效的多，而還沒生效的 coupon 與 voucher 通常都不多，所以會設計成對 ended_at 放一組 B-tree index：

CREATE INDEX ON t1 (ended_at);

這個設計不算差，不過用了一些假設。

如果不想要用這些假設，可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class)，這樣就直接對 a < x < b 這類查詢更有效率，不過缺點就是可讀性會比較差。

在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情，主要是有一般性的 int4range 與 int8range 以及時間類的 tsrange、tstzrange 與 daterange (參考「Range Types」這邊有更多資料型態)，所以會變成：

CREATE TABLE coupon (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  code VARCHAR NOT NULL,
  active_at INT4RANGE NOT NULL
);

然後用 GIST 建立 index：

CREATE INDEX ON t1 USING GIST(active_at);

後續的 query 語法就用 <@ 的語法：

SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;

塞了 10M 筆資料後的 table 可以看到本來需要的時間是：

Time: 779.542 ms

變成：

Time: 5.510 ms

不過缺點就是 SQLite 沒支援這些資料型態，對於 test case 就一定得跑個 PostgreSQL 起來測...

GitHub 的 MySQL 架構與數字

前幾天 GitHub 有寫一篇文章提到他們的 MySQL 是怎麼 scale 的，另外裡面也有一些數字可以看：「Partitioning GitHub’s relational databases to handle scale」。

他們最主要的 database cluster 叫做 mysql1，裡面有提到 2019 年的時候這個 cluster 是 950K qps，其中 primary 有 50K qps：

In 2019, mysql1 answered 950,000 queries/s on average, 900,000 queries/s on replicas, and 50,000 queries/s on the primary.

在 2021 年的時候變成 1.125M qps，其中 75K qps 在 primary 上：

Today, in 2021, the same database tables are spread across several clusters. In two years, they saw continued growth, accelerating year-over-year. All hosts of these clusters combined answer 1,200,000 queries/s on average (1,125,000 queries/s on replicas, 75,000 queries/s on the primaries). At the same time, the average load on each host halved.

另外這幾年比較成熟的方案都拿出來用了，包括用 ProxySQL 降低連線數的壓力 (connection pool 的概念)：

[W]e started using ProxySQL to reduce the number of connections opened against our primary MySQL instances.

ProxySQL is used for multiplexing client connections to MySQL primaries.

另外用 Vitess 協助 sharding 之間的轉移：

Vitess is a scaling layer on top of MySQL that helps with sharding needs. We use its vertical sharding feature to move sets of tables together in production without downtime.

這兩套應該是已經蠻成熟的了... 另外也可以發現老方法還是很好用，就算在 GitHub 這種量還是可以暴力解決很多事情。

Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看，Amazon RDS 支援了 ARM 架構的 t4g 與 x2g：「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。

目前主要是關注 t4g，因為目前量的關係反而是大量使用 t4g 類的機器，如果上面的 PostgreSQL 可以跑 t4g 的話，看起來只要沒有買 RI 的可以換過去，主要是比 t3 再省一些錢：以新加坡區的 PostgreSQL 來說，db.t4g.micro 目前是 $0.025/hr，而 db.t3.micro 則是 $0.028/hr，差不多是九折。

沒意外的話效能應該也會提昇一些，不過用 t 系列的機器本來就沒有太大的量在上面跑，這點應該是還好...

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：

但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：

另外測了 ext4/bcache，看起來效率就沒那麼好：

這樣看起來是個不錯的選擇...

MySQL InnoDB 的 OPTIMIZE TABLE 的 Lock

在 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

這在早期的時候還蠻常被拿出來用的，如果還在維護一些舊系統的話還蠻推薦的...

2019 年 Percona 對 UUID 當作 Primary Key 的看法

前陣子的「為資料庫提案新的 UUID 格式」這邊提到了有人提案要增加新的 UUID 格式，Percona 的老大 Peter Zaitsev 在 Twitter 上貼了「UUIDs are Popular, but Bad for Performance — Let’s Discuss」這篇在 2019 年時他們家的文章，題到了 MySQL 使用 UUID 當作 Primary Key 的事情：

要注意的是這篇文章沒有要從頭解釋 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 的社群沒跟那麼久...)