Tag: mariadb

MariaDB 停掉 SkySQL 與 Xpand

看到「MariaDB ditches products and staff in restructure, bags $26.5M loan to cushion fall」這篇，MariaDB 決定停掉 SkySQL (SQL service) 與 Xpand (scalable solution)。對應的 8-K 文件在 30366574-a5f7-4512-ab57-e643d1fb148d.pdf 這邊。

這兩個產品不再收新客戶，另外現有的客戶有安排轉移計畫 (大概就是告知替代方案而已？)：

As part of the Plan, the Company will focus its attention on its core MariaDB Enterprise Server database product. Products not related to the core MariaDB Enterprise Server business, including SkySQL and Xpand, will no longer be sold and the Company has implemented a plan to help existing customers migrate off these products.

至於本業的部分... 自家研發的 Aria 引擎沒有什麼賣點，與 MyISAM 相比，只有 crash-safe 的功能能看，但還是沒有 transaction 的能力。

這次是不是還有能量回歸把本業做好，就得看下去了... 話說 MariaDB 當初 2022 年是透過 SPAC 搞上市的 (參考「The MariaDB SPAC deal could prove to be a key test for unicorn exits」這個報導)，不知道 key man 股票是不是都脫手了...

MariaDB 嘗試相容於 PostgreSQL 協定的產品

在 Twitter 上看到的消息，新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊：

看起來是 SkySQL 的服務，這樣聽起來不像會 open source... 看起來賣點在於 globally distributed RDBMS 這個部分：

MariaDB is previewing a PostgreSQL-compatible front end in its SkySQL Database-as-a-Service which provides a globally distributed RDBMS on the back end.

再看看後續會不會有更多消息？

MariaDB 以及 Trac 在 arm64 上的安裝

把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.micro (都是 1GB RAM)。

就效能上來說，t4g 機器的效能很不錯，這兩年 blog 跑的也都還算順，先前公司用起來感覺也很好，然後價錢更便宜，另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢，算是會想要換的主因。

在確認應用跑得起來後，買三年 RI 是 $87.15/3y，所以機器本身的費用大約是 $29.05/y，就算加上 8GB 的 EBS (gp3) 空間費用，整體比本來在 Vultr 的 $6/mo 低不少。

上面跑的是我自己的 Trac，想搬到 AWS 上一陣子了，但有幾個不確定的因素，所以連假期間才有空多花一些時間確認。

第一個是 MySQL 的部份，我自己習慣用 Percona Server 的版本，但目前還沒有 arm64 的套件可以直接裝，要用的話就得自己編以及升級。

在 2021 年的時候 blog 搬到 AWS 的時候就遇過了，本來以為這次有機會，但看了一下還是沒支援，所以還是得用 MariaDB。

第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情，但看起來官方的動力也不大...)，這在 18.04 的時代是沒什麼問題，但 22.04 下面不知道會爛掉多少東西。

所以只能繼續用 pyenv 扛著，但已經有預期會遇到問題，加上這次又從 MySQL 轉到 MariaDB，應該也會有些地雷...

所以跳下去後遇到的問題就跟上面提到的類似，分成兩塊。

在 MariaDB 這邊第一個遇到問題是，雖然官方有提供 APT server，但沒有在 HTTPS server 上放新的 public key，所以一定得從 key server 撈。

但 GnuPG 就是沒有直接從 key server 下載變成檔案的功能，一定要先塞到 keystore 裡面再 export 出來，就覺得很...

所以就冒出利用 mktemp -d 在 /tmp 下產生暫存目錄這樣的寫法，讓 GnuPG 把 keystore 放進去，這樣至少在重開機後就會消失：

export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME

這邊為了安全性，還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8。

另外就是整理 MariaDB 需要的 my.cnf 內容，我是拿 Percona Server 5.7 的設定檔來改，只刪掉了跟 GTID 相關的設定就會動了。

而其他 MariaDB 遇到的問題主要是設計改變的問題，在 wiki 上有提到。

接下來是 Trac 1.4 的問題，本來的安裝是用 libmysqlclient-dev，然後再安裝 mysql-python：

sudo apt install -y libmysqlclient-dev
pip install mysql-python PyMySQL Pygments Trac

但單純把 libmysqlclient-dev 換成 libmariadb-dev 後，mysql-python 還是編不動，照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過，最後找資料發現要改用 mysqlclient：

sudo apt install -y libmariadb-dev
pip install mysqlclient PyMySQL Pygments Trac

搞定後後續就一路看錯誤訊息解就可以了...

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 系列的機器本來就沒有太大的量在上面跑，這點應該是還好...

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量)，就把 blog 搬到 AWS 的 t4g.small (ARM) 上，理論上頁面的速度應該會快不少，過幾天等穩定性沒問題後就來買 RI...

從 x86-64 轉到 ARM 上面，主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository，所以就改用 MariaDB 了。

其他的倒是都差不多，目前的 Ubuntu + nginx + PHP 沒什麼問題，跑一陣子看看...

Let's Encrypt 升級資料庫伺服器 (AMD YES？)

Let's Encrypt 升級了 MariaDB 資料庫的伺服器 (跑 InnoDB)，特地寫了一篇文章出來講：「The Next Gen Database Servers Powering Let's Encrypt」。

CPU 的部份從本來的 2x Intel Xeon E5-2650 (Total 24 cores / 48 threads) 換成了 2x AMD EPYC 7542 (Total 64 cores / 128 threads)，這點在本來就是 CPU 滿載的情境下改善很大：

而本來的瓶頸一解決，也使得 API 的 latency 直接降下去：

回頭看一下架構，可以看到他們提到沒有使用分散式的資料庫，而是單台 database 硬撐，驗證了即使到了 Let's Encrypt 這種規模，以暴制暴還是很有效的：

We run the CA against a single database in order to minimize complexity. Minimizing complexity is good for security, reliability, and reducing maintenance burden. We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary.

除了 CPU 暴力外，2TB RAM 與 24 顆 NVMe SSD 的搞法也是很讚的，擺明就是用記憶體拼 cache 的量，以及用大量的 NVMe SSD 疊 IOPS。

然後硬體還在成長，看起來暴力解應該會變成以後的基本答案了...

產生名次的 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 這篇文章的主要目的，推銷一下自家產品的新功能)。

文章收起來之後遇到可以拿出來參考用...

MyRocks/MariaDB 的 tuning 過程

看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。

看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：

Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.

這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：

The servers were close to their limits and were slow to catch up with replication after a maintenance period

後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。

另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。

不過在「Increased Read Load Over Time」那段還是看到了 workaround：

The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.

目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...

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 好像還好...

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

在 MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字，這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」)，說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大：

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速，在新版應該可以改善不少。但即使如此，文章內還是在實體機器上看到了 40% 的效能損失：

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了，不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的，因為接下來五年應該都還是愈的到 KPTI，應該還是有人在用 MyISAM...