Home » Posts tagged "db" (Page 19)

Mobile01 的 Ryan 換 InnoDB 的筆記與心得

沒記錯的話,Mobile01 應該是去年暑假左右從 MyISAM 換成 InnoDB 的?一切的起頭應該是蔣大「現在SSD硬碟可以拿來跑資料庫嗎?」這篇。

另外同場加映,使用 Percona 的工具讓管理上更方便:

MyISAM 是 MySQL 5.0 與 5.1 預設的 storage engine (到 5.5+ 預設的 storage engine 改成 InnoDB),讀取的效能相當好,但總是有些問題。

當時剛好有機會跟蔣大與 Ryan 聊到當時 Mobile01 遇到的問題,問了一些細節後感覺上是 MyISAM 的問題,就提了 MyISAM 與 InnoDB 的優缺點比較,以及幾個 InnoDB 的 High Availability 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器):

  • MyISAM 的讀寫互斥、寫入也是互斥。當有資料在讀取時無法更改資料庫內容,而有寫入時其他人不能讀取。另外同時間只能有一個人寫入。(有少數操作是例外,像是 bulk insert,這邊跳過)
  • MyISAM 不是 crash-safe storage engine。機器總是有機會爛掉,這時候除了重開機的時間外,還需要有修 table 的時間,對於網站的 uptime 比較痛。

這兩點是當時 Mobile01 遇到最痛的問題:用 iostat 看起來 I/O 明明就沒有滿,但就是會卡 SQL query,而當機後修資料庫的時間又很長。

一個是已經在業界驗證很久的解決方案 XFS + DRBD + Heartbeat,當機器發生問題時的 downtime 從 30secs 到五分鐘 (依照資料性質與大小而有差異,在切換上線後有資料庫的熱機問題)。

另外一個是當時還很新的 Percona XtraDB Cluster,可以避免資料庫的熱機問題,不過技術很新。

後來 Mobile01 用 RAID 10 的硬體,軟體的部份用 Debian + XFS + DRBD + Heartbeat 跑 Percona Server 的 XtraDB (InnoDB 的加強版),先用 VM 做了 PoC (直接砍掉 mysqld,或是直接關掉 VM 之類的,測試整個機制夠不夠自動化),然後就上線了 :p

記得上線那幾天跟 Ryan 聊,好像效果還不錯吧...

MySQL 上的 Thread Pool...

Percona 的人寫了一篇「Percona Server: Improve Scalability with Percona Thread Pool」,提到關於 MySQL 在連線數很多時的效能。

傳統的作法是一個連線使用一個 thread,這種方法實做起來很簡單,但當連線數超過一定程度時就會因為共用資源的限制而變慢。

其中一種解決方法是引入 Thread Pool 架構,也就是 M 個 thread 處理 N 個連線。

Oracle 有提供商用版本叫做 Thread Pool Plugin,就如同名字,是以 plugin 形式存在。這個功能在 5.55.6 都有。

MariaDB 也有 open source 實做的 Thread pool

而 Percona 則是使用 MariaDB 的版本。(原文是說有改善,不過 benchmark 並沒有列出來,我「猜」其實沒什麼改善...)

可以看到在多連線數時的效果相當好。在 MariaDB 的文件裡有提到會有改善的時機:

Threadpools are most efficient in situations where queries are relatively short and the load is CPU bound (OLTP workloads). If the workload is not CPU bound, you might still want to limit the number of threads to save memory for the database memory buffers.

query 相對短,而且是 CPU bound。

回頭看的時候發現 Percona Server 5.5 就有支援 Thread Pool 了,應該來測試看看效果如何...

AWS 提供跨區的 MySQL Read Replica...

Amazon RDS 將提供跨區的 MySQL read replication。看起來是針對 5.6+ 的版本提供這個功能...

有兩篇官方文章,一篇是 CTO 發了一篇「Expanding the Cloud: Enabling Globally Distributed Applications and Diaster Recovery」,另外一篇是官方網誌上的「Cross-Region Read Replicas for Amazon RDS for MySQL」。

用圖表示比較容易懂:

在 US-East 建立 MySQL master,另外在 EU 與 Tokyo 建立 slave replication。不知道中間的 traffic 有沒有過 IPSec 或是 SSL?

Percona 對 InnoDB 效能的建議...

2007 年的「Innodb Performance Optimization Basics」這篇是以當時的環境寫的 (MySQL 5.0)。過了六年,出了 MySQL 5.1、5.5,目前新版是 5.6。

於是就冒出這篇 2013 年版:「InnoDB performance optimization basics (updated)」。

主要是新的科技與技術讓 InnoDB 有更多選擇可以用。SSD 的發明讓 i/o 效率更好,而檔案系統的改善使得 ext4 開始被大家接受。

另外 InnoDB 自己的改善也能夠充分發揮現代硬體的能力,尤其是對多核心的延展能力。

這篇該講的都有講到,文末雖然打自家廣告推薦 Percona Server with XtraDB,不過這的確是個好東西。

Percona XtraDB Cluster 5.5.33-23-7.6...

Percona XtraDB Cluster (Galera Cluster) 出新版:「Percona XtraDB Cluster 5.5.33-23.7.6 is now available」。

看到了幾個比較特別的功能:

Desync functionality has now been exposed to the client. This can be done either via /*! WSREP_DESYNC */ comment on the query or by setting the global wsrep_desync variable to 1.

這個功能感覺上是打算為了在 Percona Toolkit 裡面配合 pt-table-sync 而準備的?

另外一個重要的功能是限速,這可以避免在伺服器最忙碌的時候加重負擔造成伺服器撐不住:

Percona XtraDB Cluster has implemented new rate limiting, rlimit, option for XtraBackup SST that can be used to avoid saturating the donor node.

以往我是自己 patch 一個 shell script 出來用,現在則變成是原生支援,那麼本來的 patch 方式就要轉換到原生支援上...

然後文末有建議 Debian 使用者在升級前要先安裝 socat,避免升級發生問題 :o

Amazon RDS 可以直接產生 Read Replica Replication 了...

以往要在 Amazon RDS 產生 Read Replica Replication 需要複雜的 snapshot 處理,但現在 AWS 直接提供這個功能了,而且可以同時生很多台:「New Read Replica Capabilities for Amazon RDS」。

這有多重要呢?以前因應流量瞬間爆增時的方式是增加 web server,並且利用 cache (可能是 memcached) 降低對後端的 query 數量。但因為引入 cache,平常就得處理 cache invalidate 的問題。

而這個方式平常只要處理讀寫分離就可以了。當量爆增時除了 web server 增加,直接增加後端的 RDS server (Read Replica Replication),甚至可以分層:

以目前的步調來看,之後有可能會推出 Master-Master 的 HA 架構?

Update:照 comment 提到的,Multi-AZ 本身就是 HA 架構了...

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 的確是依照內容的實際長度索引,而非用欄位的最大長度做。

Archives