幹壞事是進步最大的原動力
MySQL replication 通常是資料庫擴充的第一步，因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。
在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar，說明在 MySQL replication 架構下要如何處理讀寫分離。
看起來包括對 replication lag 時的處理 (slave 因為各種原因，導致跟不上 master)，有興趣的人可以去報名聽聽看... 雖然是講 PHP，但這個問題在其他的語言也會遇到，聽觀念也應該有幫助。
Mozilla 最近在升級 MySQL 採「先建後拆」的步驟，發現用 pt-table-checksum 檢查時不一致：「MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation」。
後來發現，在 MySQL 5.1 (5.1.65-rel14.0-log Percona Server (GPL), 14.0, Revision 475) 的查詢結果是：(Mozilla 的範例)
mysql> select float_field from db.tbl where id=218964; +-------------+ | float_field | +-------------+ | 9.58084e-05 | +-------------+ 1 row in set (0.04 sec)
而在 MySQL 5.5 (5.5.28a-MariaDB-log MariaDB Server) 的查詢結果是：
MariaDB [(none)]> select float_field from db.tbl where id=218964; +--------------+ | float_field | +--------------+ | 0.0000958084 | +--------------+ 1 row in set (0.24 sec)
最後是讓 pt-table-checksum 把 float/double 欄位忽略掉。在 comment 有人提出來是在 MySQL 5.5.3 的時候改變的，不過作者蠻意外沒什麼人提到...
在 Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題：「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。
用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做)，但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司，也可能是家庭) 發生 Private Network 相同而導致問題。
2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留，拿來給營運 CGNAT 的 ISP 使用：
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED NetHandle: NET-100-64-0-0-1 Parent: NET-100-0-0-0-0 NetType: IANA Special Use
在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換；如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情)：
In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。
如果 CGNAT 上不能打洞，那麼很多應用就很苦了 (得靠 UDP hole punching 打洞，這還得在沒有 randomized NAT port 的情況下才打的通)，不過非 P2P 的應用應該不會有問題...
會不會做一做之後就維持這個方式？IPv6 遙遙無期... XD
在 Twitter 上看到 John Merriman 寫的「I talked to Adobe yesterday」：
I talked to Adobe yesterday: twitter.com/jmerriman/stat…
— John Merriman (@jmerriman) January 16, 2013
這回答看起來就像機器人 XDDD
這時候就要拿出經典的「On the Internet, nobody knows you're a dog」出來：
白宮宣佈提昇 We the People 的強制答覆連署上限，將原本 25k 人提昇至 100k 人：「Why We're Raising the Signature Threshold for We the People」。
因為最近參與的人變多太多：
另外白宮給了一份 Infograph，更詳細的說明參與的狀況：
英國有個 data.gov.uk，美國有個 We the People，再加上昨天看到的 alpha.data.gov (A collection of open data from the government, private sector, and non-profits that are fueling a new economy.)，感覺台灣跟世界上的已開發國家愈差愈遠了...
看到布長輩提到：
剛開始用 104 的系統找履歷時，都用一些很爛的關鍵字搜尋：
最近找起來比較有心得了，用這些關鍵字：
還有一些相關領域的關鍵字拿來找也還蠻不錯的...
另外最後宣傳一下，敝公司找人，包括 client 開發與 server 開發都有缺。(我主要是 server 的部份，client 的部份我會轉給我同事)
有興趣可以用 gslin at kkbox.com 聯絡... (不過話說回來，我下星期去日本，cc 一份給 hr at kkbox.com 會比較好)
「分散式系統」(Distributed System) 是個老詞彙，但跟最近當紅詞彙「雲」、「NoSQL」常常相關。也因此「雲」與「NoSQL」常常遇到的都是分散式系統遇到 (並且討論過) 的問題...
而「Notes on Distributed Systems for Young Bloods」這篇寫的好血淚 XDDD 除了講理論面的東西以外，也把實務面會遇到的問題拿出來講...
首先要先知道「Fallacies of Distributed Computing」，在分散式系統裡，能假設的事情實在太少，要處理的事情太多。而「CAP theorem」也是個必讀的主題，從 Amazon 丟出「Dynamo: Amazon's Highly Available Key-value Store」這篇經典的 paper 後讓更多人知道這個理論。
熟悉上面兩個主題後，接下來就是血淚史... XD
garbage collection pauses make masters “disappear”
啊，GC 讓 master 不見... (NameNode... XDDD)
Writing robust distributed systems costs more than writing robust single-machine systems.
Robust, open source distributed systems are much less common than robust, single-machine systems.
這兩條... XD
Oh, and Paxos really is very hard to implement
Paxos... XD
If you can fit your problem in memory, it’s probably trivial.
(噴飯)
“It’s slow” is the hardest problem you’ll ever debug.
連問題都找不到嗎... XD
撇開這些碎碎念的部份，就算對 distributed system 沒那麼熟，這篇文章也提到了很多「解決的方向」以及「關鍵字」讓你找資料，對於實際操作時會有很大的幫助。
在公司搞定一個速度最佳化的問題，想到之前在 Stack Overflow 上有看到 CPU branch prediction 的問題 (跟我解的問題應該沒關係，只是剛好想到)，把文章找出來...
出自 Stack Overflow 上有人詢問某段 C++ 程式為什麼加上 sort 後快多了：「Why is processing a sorted array faster than an unsorted array?」。
發文者的範例程式已經簡化到很容易理解：先產生一個 32Kytes 的 array，然後裡面塞亂數。
接下來把每個 byte 當作 unsigned char，要找出這個 array 裡面所有值大於等於 128 的元素，把這些元素的值加起來。
原發文者發現，如果先把這個 array 排過再計算，十萬次只要 1.93 秒，但如果不排就直接計算需要 11.54 秒，時間差不多是原來的六倍。
回答的人答的相當詳細，還給了一個 branchless 的 hack 來解這個問題 (於是就不需要先 sort)，很值得一看。
Munin 是套資源監視軟體。跟其他資源監視軟體不一樣的地方？畫面漂亮啊 XDDD 拿台堆各種雜物的 database 來看：
等到 Munin 監視超過二十台時就會很明顯感覺到很吃資源，再多的時候就會開始罵三字經，罵完後拆一台獨立的機器跑，以免跑個 vim 都要卡三秒... XD
這時候就是該調整了：
munin.conf 的 graph_strategy 與 html_strategy 都改成 cgi，告訴 Munin 在更新時只要更新 rrd 資料，而圖片與 html 的資料讓 cgi 做就好，這可以大幅減少 i/o rate。rrdcached 的預設參數要記得調整。另外有些討厭的地方，strategy 設定不能放到 includedir 裡，一定得放 munin.conf 本體，這對於自建 ports 的人有點麻煩... (得用 pkg-install 與 @unexec 去堆設定，可以參考 ports-mgmt/portconf 對 /etc/make.conf 的作法)
這樣有比較有效率嗎 XDDD (而且怎麼吵起架來了 XDDD)
出自「How to Communicate your Displeasure with Neighbours using Wi-Fi」。