用 tpcc-mysql 測試 MySQL InnoDB 效能

因為跟廠商借了張 NMR8100-4i 要測試效能，而這張有兩個 50GB 的 SLC NAND Flash，想要跑看看如果拿來給 database 用的效能如何。

TPC-C 是用來模擬線上交易服務所產生的資料庫 query 藉以測試效能 (另外還有 TPC-E 與 TPC-H 是測試不同面向)。而 tpcc-mysql 則是 Percona 維護的 open source 專案，專門拿來測試 MySQL 的效能，面向則是跟 TPC-C 接近。

所以就決定拿 tpcc-mysql 來當測試工具 (因為 Percona 的關係)。

建議第一次玩的人可以在 AWS EC2 上開一台 Ubuntu server 玩看看，反正爛掉可以重來，不用太擔心要還原...

首先先安裝 bzr 與 build-essential 以及 libmysqlclient-dev，然後將 source code checkout 下來：

# apt-get install bzr build-essential libmysqlclient-dev# cd /tmp# bzr branch lp:~percona-dev/perconatools/tpcc-mysql

checkout 後要先上這個 bug report 裡面提供的 patch，雖然標題是 9.04 64bits，但在 12.04 64bits 下還是沒修正：「tpcc_start core dump on Ubuntu 9.04 64bit」。

修正完成後直接編就可以了：

# cd src# make

接下來的東西可以看 README 裡的說明。

首先先建立 database (我取 tpcc1000)，然後再把 create_table.sql 與 add_fkey_idx.sql 倒進去。

然後用 tpcc_load 產生資料塞進資料庫：

# ./tpcc_load 127.0.0.1:3306 tpcc1000 root rootpassword 1000

上面這是單一 process 在塞，可以考慮用 load.sh 同步塞 (速度快很多，不過 script 寫死用 root 塞，密碼是空的，你可以自己改裡面的內容)：

# ./load.sh tpcc1000 1000

我自己測試發現 W=100 約 10GB 資料，W=1000 約 86GB 資料。測試的時候要注意有沒有超過 memory size。通常是 fit memory 測一次，over memory 再測一次。我的例子是測 fit flash size 一次，over flash size 一次。

第一次倒測試資料進去的時候，我通常會先調整 my.cnf，讓他不要每次 flush to disk，這樣寫入速度會快很多。

雖然說快很多，W=1000 的情況下我也跑了八個小時 I/O bound 才產生出 86GB 資料。

倒完資料後要把 my.cnf 改成要測試的設定，然後重跑 mysqld，接著跑 tpcc_start 實際測試：

# ./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -prootpassword -w1000 -c32 -r 60 -l3600

上面的 -c 是 thread 數量，-r 是 warmup 時間，-l 則是測試的時間。這個例子裡會 warmup 60 秒，再加上 3600 秒的測試 (一小時)。

最後他會給你 TpmC 數字，這數字愈大表示效能愈好。

大致上就是這樣，話說回來，NMR8100-4i 這張卡帶來的效能不錯耶...

用 Percona Xtrabackup 複製資料給 slave 用

在幾乎都是 InnoDB table 的環境下，可以用 Percona Xtrabackup 產生出一份完整的資料，提供給 MySQL Slave 用。主要是參考這兩份文件：

• Making a Full Backup
• How to setup a slave for replication in 6 simple steps with Xtrabackup

我安裝 Percona Xtrabackup 是透過 apt-get，如果要用其他安裝方式也可以，這邊就不提了。

跑法是先在 master 機器上跑 innobackupex：(要記得 /data 下得有足夠的空間放檔案)

# innobackupex /data/db/
# innobackupex --apply-log /data/db/xxx/

其中第二個指令中的 xxx 是 innobackupex 產生的目錄。
等這些指令跑完後，就可以把整個目錄複製到別台使用，在 xtrabackup_binlog_info 裡面有 master 的 binlog 資訊可以讓你設定。

其中比較要注意的地方是不能加上 --compress，因為 --apply-log + --compress 會失敗，這個問題在 Percona Xtrabackup 的 Launchpad 上有看到有 ticket 在處理了。

XtraBackup 2.0.1

Percona 更新了 XtraBackup：「Announcing Percona XtraBackup 2.0.1」。

對於使用 Percona XtraDB Cluster (Galera Cluster) 的人，幾乎都應該設定 XtraBackup 為 full resync 工具。在 resync 過程中才不對讓提供資料的 server 停止服務 (如果用 rsync 當 resync 工具，會停止服務)。

這個版本修正了一個之前遇到的問題：當單檔超過 8GB 的時候會爛掉。

之前的解法是自己用 bzr 把 2.0 branch 拉下來編一個 xtrabackup-5.5 出來用 (我遇到的時候其他人也已經遇到了，patch 也已經進 branch 2.0 了)，現在只要 apt-get 裝起來就可以了...