幹壞事是進步最大的原動力
雖然現在跑到台東玩，不過還是趁著在民宿休息的時候來寫一些東西好了...
剛剛看到 Pinboard 寫了一篇關於去年 12 月時 Yahoo! 內部簡報被流出時 (參考去年寫的「Yahoo! 要關閉 Delicious」) 所帶來的流量，以及對他們的影響：「Anatomy of a Crushing」。
裡面包括了架構，兩台 DigitalOne 的 server 當作主力，以及一台 ServerBeach 的 server 當作 slave (看起來是順便當作異地備份以及一些雜物服務)：
另外也提到了 MySQL 的 varchar index 的老問題...
在「用 Plack 跑 CGI」提到用 Plack 跑 CGI，目的是把 PHP 寫的 Adminer (一個取代 phpMyAdmin 的工具) 跑起來。
文章裡提到 PHP 沒辦法以 CGI mode 執行，主要有兩個原因。一個是 PHP 本身有安全機制，php-cgi 必須在有 REDIRECT_STATUS 這個環境變數下才能執行，另外一個是 php-cgi 需要用到 SCRIPT_FILENAME 這個非 CGI/1.1 標準 (RFC 3875 - The Common Gateway Interface (CGI) Version 1.1) 的環境變數。
由於我只打算跑 Adminer，而 Adminer 的程式都放在同一個檔案裡，所以可以把這兩個環境變數設死惡搞：
env -i REDIRECT_STATUS= SCRIPT_FILENAME=/path/adminer.php /usr/local/bin/plackup -MPlack::App::CGIBin -e 'Plack::App::CGIBin->new(root => "/path")->to_app'
這樣就跑起來了...
Oracle 的公告：「MySQL 5.5 is GA!」，以及 Oracle 的新聞稿：「MySQL 5.5 Now Generally Available」。
MySQL 5.5 比起之前的版本，除了 InnoDB 的改善以外，最重要的是 Semi-Replication 成為內建功能，這個功能使得需要 Read-after-write consistency 的 query 可以不用強制綁在 master 上做...
對於開發者，MySQL 5.5 把本來用的 autotools 換成 CMake 了：「MySQL 5.5: CMake replaces autoconf/automake on all platforms, support for autotools has now been removed」。
接下來就等 Percona 出對應的版本了...
Percona 前天推出的 Percona Server 5.1.52-12.3 宣佈支援 HandlerSocket，在 InnoDB 的基礎上面提供 memcached 等級的效能... (不過還不曉得在碰到 I/O 時會掉多少)
HandlerSocket 拿 InnoDB 當作 Key-Value store 的底層，需要的時候還可以透過上層的 SQL 存取，然後 Percona 也跳下去，因為現有的資料庫就可以拿來用，可以預期會有很多人跳下去玩...
AWS RDS 支援 read replication 了：「Amazon RDS: Announcing Read Replicas」。
不過常見到的問題還是會有，像是 replication lag 以及所產生的 read-after-write 問題。但對於許多 read 需求遠大於 write 需求的應用來說，RDS 新推出的功能可以再簡化 MySQL 的設置...
WordPress 宣佈從 3.1 版開始將不再支援 PHP 4 與 MySQL 4：「PHP 4 and MySQL 4 End of Life Announcement」。
PHP 4 與 MySQL 4 官方都已經停止支援很久了，WordPress 總算是想起來了？
另外，在 WordPress 3.2 版後 (預定在 2011 年的上半年發行)，對 PHP 的最低需求會再提高到 5.2 版，這是因為目前使用非 5.2 以上的數量只有 ~11%，所以他們希望半年後可以再把需求更新...
Amazon Web Services 上星期公佈了 S3 不同等級的服務：「Announcing Amazon S3 Reduced Redundancy Storage」。
先前 S3 的系統是設計成一年內有 99.999999999% (1-10-11) Durability，這是靠比較高的 replication 數量，以及將資料放在不同機房。而 RRS (Reduced Redundancy Storage) 則是放在單一機房內，replication 數量也比標準的 S3 少，所以成本會比較低，但資料的可靠度也會比較低，只有 99.99% (1-10-4)。
這個新的設計對於比較不重要的資料 (尤其是可以從原始資料再運算得到的，像是縮圖) 可以考慮丟到 RRS。在前 50TB 的部份是標準儲存 2/3 的價錢。
另外 RDS 的部份則是支援跨區 replication 了，可以藉由這種方式提昇一部分的服務可靠度：「Announcing Multi-AZ Deployments for Amazon RDS」。
在 Amazon CTO Werner Vogels 的 blog 上提到了 AWS SimpleDB 支援不同程度的 consistency：「Choosing Consistency」，在 James Hamilton 也對這件事情發表正面的意見：「I love eventual consistency but...」。正式的技術文件在「Amazon SimpleDB Consistency Enhancements」這邊可以查到。
Eventual consistency 以 CAP theorem 中的 Consistency 妥協，試著解決 scale 問題，但缺點是 stale read (可能會讀到舊資料)，對要求比較嚴謹的子系統 (像是遊戲內的各種點數，身上帶的金幣之類的) 會很麻煩，而對於要求更嚴謹的系統 (像是商品搶購時的「剩餘數量」) 幾乎無法直接使用。
像是 Colin Percival 曾經解釋他得在 S3 與 SimpleDB 上做不少 workaround：「How Tarsnap uses Amazon Web Services」以確保資料正確性。
AWS SimpleDB 這次提供了新的功能，要求寫入時一定要等到 consistent 才 return，將 consistent 的權限放給上層 application 決定，開發者可以自己拿捏。
在 TechCrunch 看到歐盟批准 Oracle 與 Sun 的併購案了：「EU Approves $7.4 Billion Deal Between Oracle And Sun」。
對於 MySQL，歐盟同意 Oracle 所辯稱的「Oracle 與 MySQL 的主要客群不重疊」這個說法。不過幾乎所有人都悲觀面對這個事實... 現在就要看誰要帶頭 fork 出來開公司了。AskMonty 所發展的 MariaDB 可能是一組人馬，不過 Percona 所發展的 XtraDB 也有可能是另外一組人馬。
應該會混亂一陣子，同時看 Oracle/Sun 在合併案定案後的反應。
歐盟的正式公告可以在網站上查到：「Mergers: Commission clears Oracle's proposed acquisition of Sun Microsystems」。
XtraBackup 釋出 1.0 版，第一個支援 Win32 平台的版本：「xtrabackup-1.0」。
不過想了一下，實際用的機會不多，因為現在跑的備份機制是在沒有 xtrabackup 就已經弄起來的方法：利用 slave 與 snapshot 保留資料，需要的機器數量比較多，不過是個還算成熟的方法...
之前寫過「XtraBackup：線上備份 InnoDB 的好東西」與「用 XtraBackup 產生 slave」兩篇文章，需要的人可以看看，當資料量比較小 (startup 初期) 的弄法。