#innodb

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…

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…

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…

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 系列的指令應該要被整合進去，這樣…