看到 Percona 的「MySQL Ripple: The First Impression of a MySQL Binlog Server」這篇提到了 Google 放出來的專案 mysql-ripple。
這個軟體的情境是針對有很多 replica (slave) 時的情境，要解決每一個 replica 都會對 master server 產生壓力，算是 binlog 的 cache layer。
MySQL Ripple 抓了 binlog 下來後就可以模擬成 mysql server (但是只能提供 binlog 服務) 讓 replica 接，在 replica 很多的情境下就可以橫向擴充，而且因為軟體只支援 GTID 模式，所以比較好做 HA 架構 (相對於 filename + position 模式)。
大概可以歸納出是 write 很多 (所以 binlog 量很大)，但又有大量 replica 需求的情境... 目前好像想不出來有什麼情境可以拿出來用 :o
開頭我先說一下我的想法，我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋：
Hi,
A lot of interesting results here…
1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive
2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled
3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.
這次看到「Settling the Myth of Transparent HugePages for Databases」這篇，也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響，同樣馬上又看到奇怪的東西...
首先是標示與圖片不合：
Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)
Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)
不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB)，當做是標錯就好。
但這樣又跑出一個奇怪的結果，48GB 的資料量比較小，TPS 大約是 35K/33K/41K，但 112GB 資料量比較大，卻可以達到 39K/43K/41K~42K，反而比較快？我暫時想不到什麼理由...
整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch，先不管)，其中 pgbench 跑了 10 mins 與 60 mins 的版本，但是 sysbench 只跑了 10 mins 的版本？這是什麼原因...
另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients)，如果以直覺來說的話，我反而還是會打開 HugePages (yeah 純粹是直覺)，我現在比較想知道他會在 Percona 裡面待多久...
也是在「Links: February 2019」這邊看到的，裡面提到了 Percona 的「MySQL Challenge: 100k Connections」。
Percona 的測試是希望每個連線都有在做事，而不是 idle connection，這個測試有點像是卡住時的情況？看起來只有這幾個參數比較特別：
table_open_cache = 200000 back_log=3500 max_connections=110000 max_prepared_stmt_count=1000000
max_connections 開多一點算是廢話，然後因為要做事所以 max_prepared_stmt_count 也多一些，back_log 可以讓 kernel 保留來不及處理的 TCP 連線。
看起來用 sysbench 測試還撐的住，跟理論差不多，隨著連線數的增加 latency 也會增加...
上次寫了「PostgreSQL 對 fsync() 的行為傷腦筋...」提到 fsync() 有些地方是與開發者預期不同的問題，但後面忘記跟進度...
剛剛看到 Percona 的人寫了「PostgreSQL fsync Failure Fixed – Minor Versions Released Feb 14, 2019」這篇才發現在 2/14 就出了對應的更新，從 release notes 也可以看到：
By default, panic instead of retrying after fsync() failure, to avoid possible data corruption (Craig Ringer, Thomas Munro)
Some popular operating systems discard kernel data buffers when unable to write them out, reporting this as fsync() failure. If we reissue the fsync() request it will succeed, but in fact the data has been lost, so continuing risks database corruption. By raising a panic condition instead, we can replay from WAL, which may contain the only remaining copy of the data in such a situation. While this is surely ugly and inefficient, there are few alternatives, and fortunately the case happens very rarely.
A new server parameter data_sync_retry has been added to control this; if you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry to on to restore the old behavior.
現在的 workaround 是遇到 fsync() 失敗時為了避免 data corruption，會直接 panic 讓整個 PostgreSQL 從 WAL replay 記錄，也代表 HA 機制 (如果有設計的話) 有機會因為這個原因被觸發...
不過也另外設計了 data_sync_retry，讓 PostgreSQL 的管理者可以硬把這個 panic 行為關掉，改讓 PostgreSQL 重新試著 fsync()，這應該是在之後 kernel 有修改時會用到...
Percona 在過節前推出 Percona Server for MySQL 8.0 了：「Announcing General Availability of Percona Server for MySQL 8.0」。
在 Oracle 版的 MySQL 8.0 多了不少功能，像是往 NoSQL 靠的功能與 GIS 相關的功能，但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了：
Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.
Percona Server 8.0 推出 RC 版了：「Release Candidate for Percona Server 8.0.12-2rc1 Is Available」。
差不多一個月前才推出 Alpha (可以參考「Percona 要推出 Percona Server 8.0 了...」)，現在跳過中間的 Beta 直接推出 RC...
效能上應該還是吃 MySQL 8.0 的改進，Percona Server 主要是一些 patch... 這樣正式版應該也快了，不知道今年有沒有機會推出？
MySQL 8.0 從四月推出到現在也快半年了，Percona 總算是要推出對應的 Percona Server 8.0 了。目前提供 alpha 版本讓大家測試：「Announcement: Alpha Build of Percona Server 8.0」。
要把現在的 patch 都轉移到 8.0 上應該是個超級大工程，可以預期系統不會很穩定... 要用來做事的最好還是先維持 5.7，可以省掉很多麻煩。
最近在弄 MySQL 的 perforemance_schema，開起來後發現效能影響沒有很大，跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過：「Performance Schema Benchmarks: OLTP RW」。重點在這張圖：
圖上可以看到 Default 其實對效能的影響有限，另外文章也整理出來，有哪些設定對效能影響不會太大，可以考慮平常就開著：
Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.
在 Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去，但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況，用的時候自己要注意。
另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來，但有 workaround 可以硬裝進去，要玩的人也可以參考一下 XD
這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04，做一些操作時才發現是 14.04...)
Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性，再加上 MySQL 8.0 有改變 binlog 相關的預設值，所以他後續花了不少時間測試，寫了兩篇關於 binlog 對於 MySQL 效能的影響：「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。
第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響，做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌)：
而其中的 workaround 就是調整 flush 參數，讓他比較頻繁的小量寫入，而不是突然要寫很多資料。這樣一來對平均效能也許比較差，但對前端應用衝擊會比較小：
在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字：
The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.
另外有測試 ext4 與 XFS 是否有影響，就測試的結果看起來 ext4 比 XFS 好一些，但差距有限：
第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較，可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失：
It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.
雖是推銷一下自家產品在這塊還不錯 XD
