剛剛爬起來看到 feed 裡面一堆 CDNetworks 的資訊，但又看不懂到底是什麼鬼，看了官方網頁也看不出來發生什麼事情 (被 Google 併購？但也不太對，才剛看到 Admob 被買，同時就要再併購韓國的上市公司？)，結果翻其他的 feed 的時候在 TechCrunch 上面看到發生什麼事情了：「Here’s Some PR For You, CDNetworks」。

內容如同標題，我看完笑得超開心的 XDDD

我猜這應該是韓國總公司的 PR team 幹的事情？美國搞 PR 的單位應該很清楚 FTC 在十月的時候要求任何的利益交換都必須被揭露，不論是公司還是個人：「FTC Publishes Final Guides Governing Endorsements, Testimonials」。

另外 TechCrunch 自己就有用 cotendo (在頁面裡可以看到 cache0.techcrunch.com，CNAME 指到 cotendo 的 CDN 上)，也曾經贊助過 TechCrunch，不得不說很厲害… XD

在 IE7 與 Firefox 3.6b3pre 上面看都相當頓，看起來只能在 Google Chrome 上跑…

文章裡提到的其他幾個站測起來的感覺還好而且，不過有一些站整理了很多字型檔可以用，倒是可以利用…

前陣子換 Firefox 3.6 後發現上面不能跑 RefControl，寫個信給原作者問看看，他就把問題找出來並修正了。在原始網站上已經有 0.8.13 了，等個幾天 Firefox 的頁面上面應該就會一起更新。(等 review 中)

本來是用 Mason，雖然 Mason 可以用 Regular Expression，但缺少簡單的機制加入白名單的功能反而造成不少困擾。最大的問題在於在設定所有站台都送出 Host-only Referer 後，無法很簡單的設定白名單，必須考驗自己的 regular expression 編寫能力，在 exclude list 裡面一條一條設… 反倒是 RefControl 可以直接設某些 domain 為 “Normal”，所以就換回來囉…

主要是最近才發現在博客來買新書 (輕小說與漫畫) 大多數都有 79 折，加上書套費用比書局便宜，沒有必要特地去書局拿… 但博客來的系統不知道是誰設計的，Referer 擋的超嚴格，登入頁與結帳頁光送 http://www.books.com.tw/ 是不會過的…

首先是 max_connect_errors，當某一個 host 送了過多的錯誤 query 時就會擋掉這個 host 的權限。這個設定無論是在共用或是獨立的環境裡，這個值的用途都非常奇怪：在共用的環境下，我可以利用這個功能惡搞其他人，把與自己同一台 web 的站台搞爛。在獨立的環境下，擋掉自己做什麼？

第三個的 skip-name-resolve 也是一個很詭異的選項，每個連線進來就跑一次 DNS 反解？MySQL 又不是 Internet 服務…

既然 Jeremy Zawodny 提了，這陣子應該有機會改…

這次的重點還是 bugfix，外加兩個小功能。

我在「getgrgid() and getpwent() not thread-safe causes segfault in worker MPM」(原 mailing list 沒有開放 archive，所以必須到 gmane 查) 把 patch 丟上去，不過看起來 mod_fastcgi 不太會出新版了。

所以在 FreeBSD 上面就需要自立救濟… 在安裝 portsconf 後，就可以在 /usr/local/etc/ports.conf 內對 www/mod_fastcgi 指定 patch 的參數：

www/mod_fastcgi: NO_CHECKSUM=yes | PATCH_SITES=http://site/path/ | PATCHFILES=mod_fastcgi-2.4.6-threadsafepatch.patch.gz

然後把 patch 丟上 http://site/path/mod_fastcgi-2.4.6-threadsafepatch.patch.gz 裡面。NO_CHECKSUM 是因為我們的 patch 不在 distfiles 內，所以得這樣搞…

依照「InnoDB buffer pool can be severely affected by table scans」，增加了 innodb_old_blocks_pct 與 innodb_old_blocks_time，利用一些設定避免 buffer pool 被大量清空。這個方法不是很完美，但應該是堪用的，在 5.1.41 的 InnoDB Plugin 應該就會看到。

也就是說，這項議案授權美國政府，要求 ISP 阻擋某些美國政府管不到的網站。由於全球網路的交換中心在美國，如果在美國的網路系統可以被政府用命令要求阻擋某些網站，會有很嚴重的影響。

因為這個比數看起來不是參議院或是眾議院的全額，看新聞稿是「The House Financial Services Committee」通過的，不確定是不是政府內的草案，接下來看 EFF 會有怎麼樣的回應，以及其他的後續報導…

MySQL 的刪除不建議直接刪，也就是像這種 query 應該要避免：

DELETE FROM `table` WHERE `lastupdated_at` < 1234567890

因為在巨大的 table 裡面，這類的 query 可能會跑幾分鐘。

一般建議多幾筆 query 刪除：

DELETE FROM `table` WHERE `lastupdated_at` < 1234567890 ORDER BY `id` LIMIT 0, 10000

跑到適當地條件成立時為止。

會需要這樣設計，其中一個主要的原因是因為 MySQL 的 replication 架構：在 master 上面的寫入時是 multi-threading，但在 slave 上面的更新卻只有一個 thread。所以，如果有單一 query 跑太久，會造成有一段時間 master/slave 資料不一致。

另外一個可能的原因是 table 使用 MyISAM。因為 MyISAM 寫入時會鎖住 table，如果花太久時間會使得 SELECT 要等待 query 結束，這點在有 web 的服務要避免 (因為前端的 user 會卡住)。分成多次寫入可以讓 query 在兩次寫入中間取得資料。

原文的建議是將每個要刪除的 entry 都展開成一筆 DELETE，這個方法有不少壞處，應該要避免。

• 在 replication 架構下會產生大量的 binlog，雖然是徹底打散了，但反而大幅增加 client 與 server 之間的傳輸成本。
• 在 InnoDB 的表格裡，我們會把 innodb_flush_log_at_trx_commit 設為 1 或 2，確保在 crash 時仍然可以回復資料，代價是每次更新時的 transaction log 都會 fsync()，強制寫回硬碟。如果有大量的 query 進來時，會產生很大量的 random write。

折衷的辦法是使用 LIMIT 限制數量，不過這樣還不夠，因為 MySQL 會認定這個 query 在 master 與 slave 上可能會有不同的結果 (即使兩邊資料一樣，底層的 data structure 可能不同，而造成 LIMIT 後出來的 Result Set 不一樣)，為了資料安全而決定切到 ROW mode。

所以另外加上 ORDER BY `id` 確保 master 與 slave 所取得的 entry 是相同的。