FreeBSD 上 Perl 升級的問題...

以往升級 Perl 後要跑 perl-after-upgrade -f,把本來在 /usr/local/lib/perl/5.12.4 的東西搬到 /usr/local/lib/perl/5.12.5 下,然後還是要到目錄下確認有沒有東西遺漏,漏掉的還是得用 portmaster 跑一次...

現在則是改成 /usr/local/lib/perl/5.12 這樣的路徑,把最後的 minor version 拿掉,至少同個主版本升級時 (5.12.x 之間) 比較不會痛了...

不過順便趁這次換成 5.16 好了,5.12 應該也快過保了...

配合 Percona Xtrabackup 的新功能以及對 Percona XtraDB Cluster 初始化的速度...

在「2 new features added to Percona XtraDB Cluster (PXC) since 5.5.31」看到 Percona Xtrabackup 引入新功能後,在 Percona XtraDB Cluster 就能使用這些新功能加快初始化的速度。

首先是 bootstrap-pxc 這個參數:

# use this...
/etc/init.d/mysql bootstrap-pxc
# or...
service mysql bootstrap-pxc

當第一次啟動時需要對 my.cnf 的 hack (啟動完成後就可以改回來) 現在可以在參數直接處理。

另外是對 xbstream 的支援,這聽一陣子了,這邊就不講怎麼用了,原文講得很清楚。不過目前測出來的效果不怎樣啊:

文章作者是說對於小資料沒差,晚點再來看看有沒有對大資料的 benchmark...

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝),像是這樣的架構:

其中 node{1,2} 為 cluster,node3 則是傳統的 async replication,來源的 master 為 node1。

當 node1 掛掉時,我們沒辦法自動將 node3 的 master 從 node1 改指到 node2,因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值,這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的,就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO,而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後,就有機會寫成程式自動化... 這算是一個不錯的開頭 :p

在 InnoDB 下的 COUNT(*)...

MyISAM 在讀取時不會有其他人可以寫入,所以 COUNT(*) 很容易被處理。而 InnoDB 的 COUNT(*) 在不同的 transaction 裡可能會不一樣,如果硬要處理的話會變得複雜,所以目前 InnoDB 的作法是 scan 一次 (出自「Limits on InnoDB Tables」):

InnoDB does not keep an internal count of rows in a table because concurrent transactions might "see" different numbers of rows at the same time. To process a SELECT COUNT(*) FROM t statement, InnoDB scans an index of the table, which takes some time if the index is not entirely in the buffer pool. If your table does not change often, using the MySQL query cache is a good solution. To get a fast count, you have to use a counter table you create yourself and let your application update it according to the inserts and deletes it does. If an approximate row count is sufficient, SHOW TABLE STATUS can be used. See Section 14.3.14.1, "InnoDB Performance Tuning Tips".

在「Easy SELECT COUNT(*) with split()」這篇提到 InnoDB 下 COUNT(*) 這件事情,當你不需要絕對精確的值時,可以利用 INFORMATION_SCHEMA.TABLES 或是 SHOW TABLE STATUS 的資訊來判斷。

MySQL HA 的選擇...

Percona 把常見的 MySQL High Availability 選擇整理後發表成 Webinar,投影片在這裡可以看到 (以及下載):「Choosing a MySQL High Availability Solution」。

沒有太多新的東西,主要還是再次描述 MySQL HA 這塊目前沒有萬靈丹,常見的這幾個方案各有自己的優缺點,會依照環境與需求而產生不同的選擇。裡面連 manual failover + 24x7 NOC 都出現了... XD

對於不清楚有哪些 HA 架構的人,可以透過這份投影片先抓出關鍵字。對於聽過一堆 HA 架構的人,想要複習各種方式的優缺點,也可以花時間看看。至於想要找萬靈丹的人就不用花時間了,目前沒這東西 :p

利用搜尋引擎找出 GitHub 上可以被 SQL injection 的程式...

Hacker News 熱門文章看到的連結。

方法是通用的,並不限於 PHPMySQL (不過 PHP 的條件相對容易搜 XDDD),連結是到第三頁:「Search · extension:php mysql_query $_GET」。

可以看到很多 $_GET 的參數直接被傳入 mysql_query() 內...

結果 Vim 7.3 出 patch level 1000 了...

前情提要:「Vim 7.4 準備中...」,本來以為會在 1000 出現前出 Vim 7.4。

結果剛剛在 Twitter 上看到「http://ftp.vim.org/pub/vim/patches/7.3/7.3.1000」出現,這是哪招... XD

Bram Moolenaar 該不會自暴自棄決定等 9999 的時候再出 Vim 7.4 吧... XD

Percona XtraBackup 2.1.1

Percona 宣佈 Percona XtraBackup 2.1.1 (第一個 2.1 GA 的版本):「Announcing Percona XtraBackup 2.1.1 GA」。

這次的版本提供了 compact backup,備份的時候不要備份 secondary index (因為這可以再建出來),在很多 index 的表格會省下大量的空間 (以及備份的時間),不過還原的時候就得 rebuild,而非直接拿來用,算是讓操作者自己取捨...

Vim 7.4 準備中...

Bram Moolenaar 發表了 Vim 7.4 的計畫:「Plans for Vim 7.4」,不過理由居然是因為 patch level 要到 999 了...:

We are now at patch level 7.3.931. In a few weeks we would reach 999. I don't want to find out what happens if we go over that, so it's time for Vim 7.4!

目前 patch level 是 931 (參考 ftp://ftp.vim.org/pub/vim/patches/7.3/),如果是這種理由的話,這幾個禮拜 Vim 7.4 就會發行了...

剛剛才發現原來 Vim 用 Mercurial...