Home » 2009 » March

在同一台機器上同時有 BIG5 與 UTF-8 Terminal

因為連上 BBS 還是透過 BIG5 比較方便,所以現在會在同一台機器上掛 BIG5 的 screen 與 UTF-8 的 screen。

首先是修改主機的 /etc/ssh/sshd_config,增加 AcceptEnv LANG,表示 server 會接受 client 所送出的 LANG 環境變數,然後在 PuTTY 的設定裡將 LANG 設為 zh_TW.Big5 或是 en_US.UTF-8 (或是 zh_TW.UTF-8):

登入後 LANG 變數就會被帶進系統內。

然後,vim 會判斷 locale 而決定 encoding 及 termencoding,所以本來寫死的部份都要拿掉。

這樣在 BIG5 環境下可以連上 BBS,用 vim 編輯一些資料...

用 freebsd-update 將 FreeBSD 7.1-PRERELEASE 升級到 7.1-RELEASE

依照 http://update.freebsd.org/,7.1-PRERELEASE 並不在升級範圍內,所以會出現像這樣的訊息:

$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from update2.FreeBSD.org... failed.
Fetching public key from update1.FreeBSD.org... failed.
No mirrors remaining, giving up.

由於 freebsd-update 是 shell script (有很多 undocument variable 可以調整),依照「"freebsd-update fetch", fetching public key failed.」這篇的點子,有個邪惡的方法可以拐 freebsd-update,讓他認為系統是 7.1-BETA:

env UNAME_r=7.1-BETA freebsd-update upgrade -r 7.1

這個方法可以用看看... 當然,這個方法一定會有一堆問題,如果對 FreeBSD 不熟的人應該會吃鱉 XDDD

Amazon EC2 推出「年租不可抵」制度

Amazon EC2 推出「Reserved Instances」費率,以最小的 instance 為例,你先付了 USD$325,他把 USD$0.1/hour 的機器費用降到 USD$0.03/hour (三折)。

基本上與手機的「月租不可抵」型意思是一樣的,只是他是年約。

假設以 365 天都租用最小的 instance 計算,本來是 USD$876,現在只要 USD$587.8,大約是 33% 的 discount。原來的計價方式與 Reserved Instances 的交錯點在 193.45 天,換句話說,要超過半年多才會比較划算,對一般人應該是沒有什麼影響。

MySQL HA 與 Slave 的關係

上面一篇「MySQL HA」其實是要提 Mark Callaghan 所寫的「Global transaction IDs are hot」這篇文章。

在三種架構下,DRBD + Heartbeat 的系統要加掛 slave 是最容易的,因為 master server 雖然跳動,但 replication 位置不會變。

在 Master-Master 架構下,由於兩台 master 都有自己的 binlog,會使得 master 跳動時 slave 產生問題,也就是在 Mark Callaghan 文章裡所寫的三種解法 "switch and hope"、"check and lose"、"check and fix"。

這三種解法都並沒有很完滿的解決問題 (第三種解法雖然看起來有 "fix",但是透過工人智慧手動解決)。

一種方法是引入 Global transactions IDs,這是由 Google 提出的 patch:「MySQL Hierarchical Replication & Global Group IDs」,對 binlog 每筆 transaction 都加上一組 64bits 且遞增的數字,這樣 slave 就不會受到 master 切換而產生 replication err。

先記錄下來,之後很有可能會透過 Google 又找到自己寫的文章...

Update:看到「High Availability for MySQL: Considering the Options」這篇文章,要如何做 HA。

MySQL HA

MySQL 有幾種不同的方法實做 High Availability 架構:

  • Master-Slave Replication,當 master 當掉時,將 slave 提昇為 master。
  • DRBD + Heartbeat,透過網路對 Disk 層 RAID1,平常只有一台會 mount 並跑 mysql,當掉時會跳到另外一台。
  • Master-Master Replication,當其中一台當掉時直接到另外一台使用。

這三種方法各有不同的缺點,舉例來說:

  • Master-Slave Replication:master 當掉時可能有 transaction 已經寫入,但尚未被送到 slave 而造成不同步。
  • DRBD + Heartbeat:當備援機跳起來時,記憶體內都還沒有 cache,會造成剛跑起來時 MySQL I/O bound,有時候叫做 "warm up problem"。
  • Master-Master Replication:query 會有 race condition (同時在 db1 下 DELETE FROM table1;,以及在 db2 下 INSERT INTO table1 SET col1=1;,有可能最後在 db1 上有資料,但在 db2 上沒有資料),這點可以用把寫入固定到某一台而避免,但由於也是 replication 類的架構,也會遇到 Master-Slave Replication 所敘述的問題。

由於資料的正確性會比其他的因素重要,現在我還是偏好用 DRBD + Heartbeat。因 query 的特性而不會有 query dependency 問題的系統才會用 Master-Master。

選擇 MySQL 用的硬體

5 Minute DBA – Database Server Hardware Selection」講了一些幫資料庫選擇硬體的方式,其實是偏向 MySQL...

簡單的說,CPU 超過 8 CPU 其實意義不大,不需要買 4*4core 或是 4*6core,因為 MySQL 目前無法利用到。

記憶體愈大愈好,記憶體現在便宜許多,如果有 I/O bound 的問題,除了改寫程式外,直接把記憶體加到 32GB 或是 64GB 通常是最划算的方法。

硬碟愈快愈好,有 Hardware RAID10 (要有電池) 會比軟體的 RAID10 好,不過這主要看需求,如果是 CPU bound 的應用,說不定 SATA 硬碟就夠用?

網卡請務必用 GigabitEthernet,最好是 bounding/trunking,除了增加 thoughput 外,也可以當作 redundant link。然後作業系統一定要選 64bits,不然會受限於記憶體可定址空間。

FFmpeg 0.5!

這實在太令人震驚了,FFmpeg 居然釋出 0.5 版 XDDDD

雖然很久沒有 release 新版,但其實 mailing list 上相當活躍,而且更新的速度也都蠻快的。我以為 developer 都已經很習慣叫大家用 Subversion/Git 拉回來編了... XD

在 FFmpeg 的首頁上有放一份簡短的 feature list,這邊就不列了。

CDN - 要怎麼挑業者

要挑什麼 CDN 是依照需求而決定,我會談的是台灣的情況。

在台灣有「用戶」的 ISP 中,HiNetTANet 的出國線路狀態是最差的,其他 ISP 的情況會好很多,所以測試的重點要放在這兩個 ISP。

以影音來說,由於傳輸時間普遍會大於一秒,重點在於 bandwidth 而非 latency。所以到台灣抓與香港、日本,甚至到美國抓其實都 okay,只要 thoughtput 夠高就可以。以 1M 高畫質的影片換算,有穩定 150KB/sec 的速度其實就很順,如果是 600K 或是更低,有穩定的 100KB/sec 以上就 okay。

如果是 css/javascript,因為檔案很小,latency 就變得很重要。可以從台灣本地提供檔案通常是最好的 (<10ms),或是從日本、香港 (~20ms 到 30ms) 提供,如果 CDN 業者可以幫忙 gzip 會更好 (因為他們會處理 IE6 的一卡車問題)。

如果檔案是屬於下載性質,速度其實不是重點,重點在於成本的話,有些 CDN 業者有提供「經濟型網路」,通常是用北美較便宜的點提供下載。有一定的 commit 時會比 Amazon S3 的 USD$0.17/GB 便宜。

除此之外,會因為不同的性質,要考慮的還很多...

Archives