MySQL 5.6 可以唯讀狀態掛起 InnoDB 資料了...

在「InnoDB now works with read-only media」這邊看到 MySQL 從 5.6.7 開始,可以在唯讀狀態掛起 InnoDB 資料:「14.2.6.1. Support for Read-Only Media」。

這對 recovery 相當方便,尤其是人為失誤 (人為下錯指令 TRUNCATE 或是 DROP TABLE) 時可以馬上從 read-only snapshot 掛一份起來複製資料。

Percona XtraDB Cluster (Galera Cluster) 的教學

Percona 將在台灣時間 9/20 清晨 (當地 9/19 10:00AM) 舉辦 Percona XtraDB Cluster (Galera Cluster) 的教學:「Upcoming Percona XtraDB Cluster – Installation and Setup webinar」。

這是偏向營運方面的 Web conference:除了安裝與設定以外,還準備試爆與修復,另外使用 HAProxy 達到 HA 目的... (我是偏好 Heartbeat + 自製的小 script 達到 HA)

有興趣的人可以報名,如果時間上不能配合的人,照慣例事後應該也有 video 與投影片可以看... (不是很確定)

又有一家大的 MySQL distribution 支援 Galera Cluster...

Galera ClusterCodership 所提供的 MySQL master-master 方案,與其他 master-master 方案比起來,最大的好處就在於比較不需要擔心資料同步的問題...

剛剛看到,除了 Percona 外,又有一家 MySQL distribution 支援 Galera Cluster:「MariaDB Galera cluster released」。這次是 MariaDB 宣布支援 Galera Cluster。

MariaDB 是由 MySQL 創辦人 Michael Widenius 發展的版本,算是一個蠻有名的分支... 這樣一來 Galera Cluster 應該會有更多人關注使用...

COSCUP 2012 的投影片:MySQL System Stability

因為大約只有 25mins 的時間,如果用傳統的方式先用 20mins 講,再用 5mins 開放 Q&A 看起來沒講到東西又沒回答到問題。

所以這次打算用不一樣的方式,先放出投影片,準備 25mins 都是 Q&A 的時間。(而且時間是 12:30 結束,提前結束還可以先吃飯?)

請享用...

InnoDB 的 Table Lock

InnoDB 設計上允許同時讀寫,在大多數的情況下不會產生 table lock,不過還是有機會。(或是刻意產生)

在「Innodb Table Locks」這篇文章提到 InnoDB 的各種 lock (都是帶過而已,不過當關鍵字去 Google 找應該是夠用了),在文章最後面整理出結論,第一個是:

MySQL Table level locks and Innodb Table Level locks are two separate beings.

而就算是 InnoDB,你也還是可以用 LOCK TABLES,效果的確會如同你想的,只是這並不是由 InnoDB engine 實作。而最後是這樣建議:

It is a good practice not to use LOCK TABLES when you're using Innodb Tables.

另外註解也有提到 auto inc primary key 偶而也會造成問題,都可以當關鍵字去找出細節 :p

Reply to「長野雅廣 (Masahiro Nagano) 的 MySQL Beginners Talk」的 comment :p

對 MySQL 的 VARCHAR 欄位使用 INDEX 時可以增加效率的方法...

MySQL 中,如果你有 VARCHAR(255) 這種欄位,不要對直接對這個欄位下 INDEX。因為 key 會以最大長度 255 chars 為固定大小,而非動態決定 (latin1 的時候 1 char 是 1 byte,utf8 是 3 bytes,utf8mb4 是 4 bytes),當資料有 1M row data 就直接吃掉 1MB/3MB/4MB 的空間。

解決方法是利用「index 可以指定只取前面 n chars」這個功能來做,至於 n 要取多少就是要估算了... 在「Optimal index size for variable text in MySQL」這篇把要怎麼做的過程寫得還蠻完整的。

同樣的道理也可以用在固定寬度的 BINARY(16) 系列上。

MySQL 的 Unicode 支援程度

MySQL 5.5 之前的版本只支援 Unicode 3.0 (1999 年 9 月發表),但自從 MySQL 5.5 版開始支援 Unicode 5.0 (2006 年 7 月發表),對於常用的 utf8 encoding 就有一些變化要注意...

參考維基百科上對 Unicode 版本的說明:「Unicode#Versions」,以及 MySQL 5.5 的文件:「MySQL :: MySQL 5.5 Reference Manual :: 10.1.10 Unicode Support」。

在 MySQL 5.5 之前,UTF-8 的設計最多吃 3bytes,因為 1byte 有 128 種組合 (7bits),2bytes 有 2048 種組合 (11bits),3bytes 有 65536 種組合 (16bits),共 67712 個空間可以用,但 Unicode 3.0 只用掉 49259 個。

而從 MySQL 5.5 開始支援的 Unicode 5.0 需要 99089 個空間,所以需要用到 4bytes 的版本,也就是增加 4bytes 的 2097152 種組合 (21bits),共 2164864 個空間。

但為了相容性,MySQL 5.5 的 utf8 encoding 還是使用 Unicode 3.0 版本。只有當特別指定 utf8mb4 encoding 時才會用到 Unicode 5.0 版本。使用 utf8mb4 encoding 時,要注意 client 端也要支援,不然會讀不到東西...

AWS 可以開超小台 (t1.micro) 的 MySQL RDS 了...

今天看到 t1.micro 也可以開 MySQL RDS 了:「Amazon RDS MySQL Now Starting at Just $19 a Month」。

拿來堆資料應該還不賴?只要 24 小時可以塞完一天的份,而且不會影響到 t1.micro 的 EBS I/O 就可以用?:p

長野雅廣 (Masahiro Nagano) 的 MySQL Beginners Talk

長野雅廣的「MySQL Beginners Talk で LT してきました」這篇 slide 對不熟悉 MySQL 的人講了兩個幾乎不會錯的觀念:

先討論後面這點,算是任何 database 都通用的法則:當你遇到效能問題時,監控機制可以提供毛線球的線頭,讓你知道慢在哪裡:什麼時間滿載 (於是可以猜測是 cron job 造成,或是對應 MRTG 圖時知道是一般使用者造成的流量造成),另外可以知道瓶頸是在 CPU (是單顆 CPU 滿載,還是整台機器都被吃滿),I/O (是讀取滿載,還是寫入造成滿載),或是網路。

前面這點解釋成「如果你不知道你在做什麼,就用 InnoDB Plugin 吧」,對於初學者 (slide 的標題),就簡化成「既然你是初學者,你就用 InnoDB Plugin 吧」。原因是:

  • InnoDB 是 crash safe engine,MyISAM 不是。
  • 常被用到的 table 其實會被 cache 在記憶體內,用 MyISAM 與 InnoDB 差異不大。
  • 最重要的一點是,InnoDB 有支援 transaction (MVCC),在大量寫入時比起 MyISAM 比較不會產生 table lock。由於 InnoDB 支援 transaction,所以功能也比 MyISAM 多。

slide 不長,但這兩個重點還蠻重要的...