Xiph 講數位訊號...

Xiph 是個網路多媒體相關的 open source 組織,前陣子放了教學影片,介紹多媒體的理論:「Xiph.org: Video」,目前每一集都大約半小時,可以下載下來或是直接在網站上看。

第一課「Episode 1: A Digital Media Primer for Geeks」從數位訊號開始講,包括影像與聲音。第二課「Episode 2: Digital Show & Tell」則是介紹聲音的部份 (包括數位與類比)。

有興趣可以去看看 :p

MySQL 平行執行的 Replication...

MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到,在 5.6.3 之前的版本,MySQL replication 都是 single-threaded,所以當 master 可以充分發揮多 CPU 能力時,slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說,假設 master server 上有兩個 thread 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2,也假定是 CPU bound,也需要跑 100 秒)

假設 thread 1 先執行完,這時候 slave 就會在跑完的時候收到 SQL 1,然後把資料同步進去。等到 100 秒過去後,再跑 SQL 2,再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣:

兩個 SQL query 可以同時跑。

到了 slave 時,在 MySQL 5.6.3 之前的 replication 會變成這樣:

可以看到還是得先執行 SQL 1 再執行 SQL 2,所以最長會有 200 秒的 replication lag。

而 5.6.3 之後支援 multi-threaded replication,可以用 slave_parallel_workers 指定平行執行 SQL query 的數量,這讓 master server 與 slave server 之間的 replication lag 降低不少:

在收到同步的 SQL 指令後就可以同時跑,這讓 replication lag 降到 100 秒。

不過還是要提,如果希望把資料同步問題降到最低,那麼 Galera Cluster 可以解的更徹底,不論是寫入的那台 master server,或是其他的 master server (在 Galera Cluster 架構裡都是為 master),一律都是同步執行:

不會有 master server 與 slave server 不同步的問題,可以減少很多 application 層的麻煩...

RAID5 會遇到的 Multi-disk failure 問題

How multi-disk failures happen」這篇畫了不少圖解釋在 RAID5 上面偶而會遇到的 Multi-disk failure 問題 (RAID6 也會,風險比較低而已)。

RAID 5

平常壞軌時,RAID 系統不一定會發現,直到 RAID rebuild 時讀過所有的磁區,系統才發現其他壞軌,造成第二顆被標為損壞... (推論到 RAID6 的情況就是再發生一次)

這在 I/O 比較頻繁的 RAID 比較不容易發生 (因為在量小的時候就容易偵測到)。

對於比較閒的系統,應該放個 cron 跑 dd if=/dev/XXX of=/dev/null 嗎?:p

用 Lbzip2 解壓縮

手上抓了幾個 .bz2 的檔案要 bzcat 出來 pipe 丟給 Perl script 跑,用系統預設的 bzip2 發現速度卡在解壓縮,而不是 Perl script...

用 parallel 與 bzip2 當關鍵字到 apt-cache 裡面找,有找到兩個套件:Lbzip2Pbzip2,都裝起來後測解壓縮的功能,發現 Pbzip2 解壓縮時沒有辦法利用到多核心的優勢,而 Lbzip2 則是很順利的超過 100%,輸出結果讓 Perl script 也吃滿 CPU resource...

如果是壓縮時需要壓縮率,還是用 xz 就好...