Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇,裡面提到了 Percona 包的 Galera Cluster,叫 Percona XtraDB Cluster

Percona 算是把 Galera Cluster 包的比較好的 distribution,是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本,叫做 MariaDB Galera Cluster

這篇算是很早期使用 PXC 的人的一些感想:(大概是 2012 年導入,當年雲端也還沒流行,在地端上面自己建,對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的,加上一台沒有資料,這台沒資料的只負責投票組成 quorum,不需要到三台都是大機器,而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入,但實務上會建議都集中在一台寫,這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素,將兩台有資料的機器,一台做 writer,另外一台做 reader 算是常見的架構,然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構,或是後來政治改名為 source-replica 架構),不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題,現在有 GUID 後會好一些)

除了 Galera Cluster 外,另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD:因為 DRBD 可以在兩台機器的 block 層做 mirror,所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純,維護成本也很低,但缺點就是 recovery 的時間會高一些:在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID),而 Galera Cluster 因為等於是 hot-standby,蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上,Galera Cluster 也是因為 hot-standby 大勝:DRBD 這邊的情境等於是 cold start,資料庫內還有很多東西還沒進到 InnoDB buffer,對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西,但後面運作的機制複雜不少 (而且需要有人維護),公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況,讀取速度與 random access 的效率都快很多,這使得 DRBD 切換的成本低很多了,很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定,如果這個時間是可以接受的,用 Galera Cluster 的優點可能就沒那麼高了...

scp -3:直接對兩個 remote host 複製檔案

剛剛找資料才發現的,scp 指令早就可以針對兩個遠端複製檔案了:「scp from one remote server to another remote server」。

可以加上 -3,像是這樣:

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加,因為這是 default 值:

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期,是 2014 年十月回的,所以至少 Ubuntu 16.04 就有這個功能了?(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬,然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案,沒想到隔壁棚早就給了解法...

這樣有些情境搬檔案就簡單多了...

目前最老的 BitTorrent 種子 20 年了:The Fanimatrix

The FanimatrixBitTorrent 種子是目前還活著的 BitTorrent 種子最老的,從 2003 年九月建立的種子,至今要 20 年了:「The World’s Oldest Active Torrent Turns 20 Years Old」。

在 2022 的報告裡面 BitTorrent 的流量大約是 2.91% (雖然這份報告本身有些地方很詭異,但就還是可以當個參考):「2022 Global Internet Phenomena Report」,在「BitTorrent is Still the King of Upstream Internet Traffic, But for How Long?」這邊也在討論 BitTorrent 的占比逐漸下降。

但這就是 open protocol 的特性,你沒辦法殺掉他,而且他在對應的領域還是活的很好...

cURL 放入 ipfs:// 支援

Hacker News 上看到 cURL 支援 ipfs:// 的消息:「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題:

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理,如果本地端有的話就用本地端的 gateway,不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援,但還行...?

Kagi 又恢復 $10/mo 的 Unlimited Search Plan 了

Kagi 公告 $10/mo 的 Unlimited Search Plan:「Unlimited Kagi searches for $10 per month」。

今天公告以後可以看到有個比較抖一點的成長,但要再觀察看看是不是持續的:

翻了一下文章,還是沒看到為什麼要這樣做,尤其是財務上的理由... 最早從 $10/mo 漲到 $25/mo 就是成本問題,我的猜測是現在有量了所以 discount 比較好談 (從 9/6 的「Kagi Search Stats」的 8034 與現在的相比,的確可以看到一直在成長),然後談完 discount 後重算成本結構,發現有機會衝一波?

也有可能是 VC 那邊有進展?像是找到比較願意放手讓 Kagi 執行這樣的理念的 VC?

Anyway,$10/mo 又回來了...

Golang 將改變常見的 closure 地雷

在「Fixing for loops in Go 1.22 (go.dev)」看到的,原文在「Fixing For Loops in Go 1.22」這邊。

算是各種有 closure 的程式語言會遇到的經典問題,下面的 Golang 程式在撰寫時會預期輸出 abc (不保證順序),但實際上會輸出 ccc,因為變數的 scope 設計原因:

func main() {
    done := make(chan bool)

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func() {
            fmt.Println(v)
            done <- true
        }()
    }

    // wait for all goroutines to complete before exiting
    for _ = range values {
        <-done
    }
}

這在 JavaScript 也是個經典的問題,搜「javascript closure loop」就可以看到「JavaScript closure inside loops – simple practical example」這個例子,對應的答案則是有提到 ES6let 因為改變了變數的 scope,可以用來解決這個問題。

剛好 let 也是 best practice 了,所以現在 JavaScript 這邊遇到這個問題的情況會少一些。

回到 Golang 這邊,Golang 是打算改變在 for loop 時,對應變數的 scope 來解決:

For Go 1.22, we plan to change for loops to make these variables have per-iteration scope instead of per-loop scope. This change will fix the examples above, so that they are no longer buggy Go programs; it will end the production problems caused by such mistakes; and it will remove the need for imprecise tools that prompt users to make unnecessary changes to their code.

另外因為這是 breaking compatibility 的改變 (畢竟有些程式碼是清楚知道這個特性而刻意這樣寫的),所以會有對應的措施,只有在有指定 Golang 1.22 或是更新的版本才會用新的 scope 編譯:

To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files. This per-module decision provides developer control of a gradual update to the new semantics throughout a codebase. It is also possible to use //go:build lines to control the decision on a per-file basis.

Cisco 併購 Splunk

Hacker News 上看到的消息,CiscoSplunk:「Cisco Acquires Splunk (splunk.com)」,對應的新聞稿:「Splunk and Cisco Unite To Accelerate Digital Resilience as One of the Leading Global Software Companies」。

看不太出來為什麼 Cisco 要買 Splunk 這家公司,不知道戰略是什麼...

另外在 Hacker News 上的討論整片都有提到 Splunk 貴到哭爸的事情... 剛好前公司也有用,那個價錢的確是很哭爸,也因此有了後續 migrate 到 Prometheus 上的計畫,不過這也是過去式了...

That's staff, the building, equipment, power, water, everything...the estimated Splunk cost was more than that.

The joke used to be 'splunk is amazing until the first invoice comes in', it's funny because it's true. Note Datadog is very similar in that regard.

現在已經比起 Splunk 出來的年代,多了很多 open source 的方案可以選擇,Splunk 的吸引力低很多了。

Ruby 3.3 的速度再次提升

在「Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster」這篇提到了 Ruby 3.3 的速度再次提升的消息。

Shopify 上面的測試,3.3.0-preview2 的速度已經比 3.2.2 (兩者都有開啟 YJIT) 快了 13%,而且 p50/p90/p99 都有對應的改善:

不過有提到一些要注意的點,像是記憶體的用量又會再更高 (本來開 YJIT 的時候就已經有增加了),如果是對記憶體比較敏感的環境,會需要注意這點:

Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. We’re looking into skipping compilation of paths that are less frequently executed.

但 server 端應該是還好 (記憶體給多一點),整體是個可以期待的方向...

Google 翻譯的中文詞彙

先前在網路上看到「Google 翻譯修好了沒? Has Google Fixed Translate Yet?」這個網站,看起來是 2021 年的時候建立的,整理出來希望可以改善 Google 翻譯在台灣所使用的中文 (zh-tw) 的翻譯品質,上面列了五十幾個詞彙,記得當時只有一個有修正,其他都還是中國或是香港的用語。

(話說 Google 翻譯的介面好像沒有分台灣跟香港...)

因為看到有英文的說明,就順手丟上 Hacker News:「Has Google Translate been fixed yet? (isgooglefixed.tw)」,還蠻意外的有些關注與討論... 大概是因為這樣,可能讓 Google 內有個整理過資料可以開 issue,過了一個月,上個禮拜陸陸續續被修正了不少詞彙,目前剩下的那幾個比較接近詞彙準確性的問題。

下一個可能是 Google Maps 上面的翻譯問題?就算切到 zh-tw 下還是會出現港式翻譯:

而把 Google Maps 英文版上看到的「Chophouse restaurant」丟進 Google Translate 翻譯是:

Linux Kernel 後續的 LTS 版本將縮短成兩年

在「Long-term support for Linux kernel to be cut as maintainence remains under strain」這邊看到 Linux Kernel 後續的 LTS 版本將縮短成兩年的消息:

Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

主要的原因是舊版用的人並不多:

Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

而目前的 LTS kernel 還是會走完本來計畫的時間,4.14、4.19、5.4 以及 5.10 從表上看都是六年,5.15 是五年,最新的 LTS 6.1 則是四年。

降到兩年的話,代表各家 Linux distribution 在 LTS kernel 跑完生命週期後就得自己維護安全性更新了,或是直接升級到另外一個 kernel 版本 (後者的方法風險高一點,不確定系統的相容性)。

看起來 5.10 與 6.1 會跑很久了,都到 2026 年十二月...