MySQL 對 VARCHAR 的 Index 空間佔用的問題...

之前不知道從哪邊學到錯的東西... 實驗後發現搞錯了。對 MySQL 的 VARCHAR 欄位下 index 所實際佔用的空間仍是實際大小,而非最大長度。

測試方法是建立表格,schema 是 CREATE TABLE test (id INT UNSIGNED PRIMARY AUTO_INCREMENT, data VARCHAR(255)) ENGINE=InnoDB;,在 inndo_per_file 打開的情況下測試。

這是 1M rows,其中 data 都是 "a",這是 OPTIMIZE TABLE 後的結果:(以下每個都有 OPTIMIZE TABLE)

-rw-rw---- 1 mysql mysql     8586 Jul 30 22:42 test.frm
-rw-rw---- 1 mysql mysql 37748736 Jul 30 22:42 test.ibd

這是 ADD INDEX (data) 後的結果:

-rw-rw---- 1 mysql mysql     8586 Jul 30 22:46 test.frm
-rw-rw---- 1 mysql mysql 50331648 Jul 30 22:46 test.ibd

一樣是 1M rows,但 data 都是 "a" * 100 (一百個 a) 的結果:

-rw-rw---- 1 mysql mysql      8586 Jul 30 23:14 test.frm
-rw-rw---- 1 mysql mysql 146800640 Jul 30 23:15 test.ibd

這是 ADD INDEX (data) 後的結果:

-rw-rw---- 1 mysql mysql      8586 Jul 30 23:21 test.frm
-rw-rw---- 1 mysql mysql 260046848 Jul 30 23:23 test.ibd

實驗可以看出來 MySQL 的確是依照內容的實際長度索引,而非用欄位的最大長度做。

AWS CloudFront 與 Route53 增加印度機房...

官方的公告在「Amazon CloudFront & Route 53 Expand to India」這篇,一次增加兩個點,孟買 (Mumbai) 與清奈 (Chennai)。

CDN 頻寬的部份比香港、新加坡、南韓還低... 被放在 Price Class All 與 Price Class 200。所以量很大?還是因為其他原因?澳洲也才放一個雪梨...

咦,俄羅斯好像一直被遺忘...

PostgreSQL 筆記...

純粹是筆記...

對於架設 server 的文件可以參考 Ubuntu 這份「PostgreSQL - Community Ubuntu Documentation」,雖然 Debian 官方也有一份「PostgreSql - Debian Wiki」,不過沒講到遠端這塊...

設定的部份:

  • 要讓遠端可以存取有兩個地方要開,一個是 postgresql.conflisten_addresses 改成 "*",另外一個是增加 pg_hba.conf 遠端連線的權限。
  • CREATE USER test WITH PASSWORD 'test_password'; 以及 CREATE DATABASE test WITH OWNER = test; 把基本的東西建好。

然後把 firewall 打開,接下來就可以從其他台連進去了。

Bootstrap 3 RC1

Bootstrap 3 RC1 放出來了。

官方在文件裡推薦使用 NetDNA 提供的 CDN Hosting,不過 NetDNA 給的點沒有很好,台灣與日本都會到美西。如果很要求速度的話 (尤其是第一次沒有 cache 時瀏覽的速度),還是放一份到自家的 server 或是自家的 CDN Hosting 上吧?

最大的改變在於扁平化,等一下就來測試看看感覺如何...

Percona 的「Advanced MySQL Query Tuning」...

先前在「Percona 要講進階的 MySQL Query Tuning...」提到 Percona 所辦的 Webniar「Advanced MySQL Query Tuning」的投影片放出來了:「Advanced MySQL Query Tuning」。

這份內容需要 B+Tree 操作的背景知識才能了解。裡面講了很多 GROUP BYORDER BY 混用時的 index 技巧,以及各種奇怪的 hack 方式。

內容很有用,能吸收多少就看個人造化 :p

Debian 上 Apache 2.2 設定 FastCGI 模式 PHP 的方式...

Debian 上只有 mod_fcgid 可以用,沒有 mod_fastcgi,兩者設定方式不一樣,花了一些時間測試...

最後是參考「Debian, apache2, virtualhosts, FastCGI and PHP5」這篇文章的說明,先弄到「會動」的情況。

首先是把該裝的裝起來 (apache2-mpm-workerlibapache2-mod-fcgidphp5-cgi),接下來在 /etc/apache2/sites-available/default 裡面修改兩個部份。

首先是針對 /var/wwwOptions 加上 ExecCGI。另外找個地方加上:

AddHandler fcgid-script .php
FCGIWrapper /usr/lib/cgi-bin/php5 .php

然後重跑 apache 就會動了,放個 phpinfo(); 的程式到 /var/www 下測試就可以確認了。

Percona 的 Crash-resistant replication

前幾天 Percona 寫了篇文章說明自家專有的 Crash-resistant replication (用在 Percona Server 5.1 與 5.5):「Crash-resistant replication: How to avoid MySQL replication errors」。

這是 async replication 用在 slave server crash 時的保護機制。

當 slave 更新資料後,會更新 relay log 寫下「目前 apply 到哪個位置」(預設值是 relay-log.info),也就可以依照這個資訊計算出 replication lag 的時間。在 mytop 裡看到的 Delay 欄位就是由此算出來的。

但當 MySQL 寫入後,但 relay-log.info 還沒更新時當掉,會造成下次啟動時重複 apply 同一筆資料。

而 Crash-resistant replication 就是把這個資訊寫到 transaction 內,避免這個問題。

也因此這個功能只有 InnoDB 類的 Engine 才有用,MyISAM 仍然是不受 Crash-resistant replication 保護的。

要打開這個功能也很簡單,只要 my.cnf 設起來就好了,設定說明可以參考原文。