熱 MySQL 的方法...

看到 jnlin 寫的「利用 Percona Playback warm-up MySQL 資料庫...」,把之前用到的「用 pt-find 加熱 (暖機) InnoDB table」改良讓他可以平行跑,儘可能吃完 I/O capacity:

pt-find --charset=utf8 --print -h $1 -u USER -p PASSWORD | xargs -t -P8 -I% -n1 sh -c "echo 'SELECT COUNT(*) FROM %;' | mysql -h $1 > /dev/null"

在 PostgreSQL 裡分析 PostgreSQL mailing list 行為...

在「Analyzing PostgreSQL Email Archives with PostgreSQL」這篇文章看到的,用 PostgreSQL 所提供的功能找出一些資訊... (像是 full text search 的功能)

於是就產生出這樣的圖:(應該不用解釋?)

還有「Probability that a new thread gets a response」或是與 Competitors 相關的統計 XD

用 Percona XtraBackup 備份時用 compact 模式節省空間...

在「Feature preview: Compact backups in Percona XtraBackup」看到的,2.1 版會導入 compact backup 節省備份出來的空間 (目前是 2.0):

As you may know InnoDB PK (Primary Key) contains all data, and all secondary indexes are only subset of columns of Primary Key. So in theory we can store only PK, and re-build secondary indexes as we need. Well, now it is possible not only in theory.

secondary index 可以事後再建,所以有兩種表格會省下很多資源:

  • Index 很多的表格。
  • PK 欄位空間很大的表格 (像是用 VARCHAR(255) 當 PK)。

等出了再來研究看看對 Percona XtraDB Cluster (PXC) 重新同步可以加快多少...

Instagram 說明用 PostgreSQL 的五個優點...

先不管 Instagram 最近的負成長以及反駁,剛剛在 Instagram Engineering 上看到對 PostgreSQL 的稱讚:「Handling Growth with Postgres: 5 Tips From Instagram

FacebookMySQL 的領域裡的實力以及貢獻度可是數一數二,但 Instagram 在被 Facebook 買下後仍然繼續使用 PostgreSQL,總是有些原因存在... 雖然真正的原因不一定是技術,但這篇試著用技術解釋的內容還是可以看一看,了解 PostgreSQL 有哪些特點...

第一個是講 partial indexes,這與 MySQL community 常講的 partial index 是不同的東西。

MySQL 的 partial index 是指只 index 某個欄位的一部分,像是 VARCHAR(255) 裡面只 index 前面的 10 chars;而 PostgreSQL 的 partial indexes 則是指符合某個條件的 row 才 index。

第二個是 functional indexes,可以針對欄位計算後再 index。MySQL 的 partial index 在 PostgreSQL 裡可以用 functional indexes + substr() 達到相同的效果,而且還有其他 function 可以用,花樣更多。

兩個都是 MySQL 做不到 (或是做不好),但 PostgreSQL 做的不錯的。一般在 MySQL 要達到 PostgreSQL 的這兩個功能需要另外開一個欄位,在裡面儲存去正規化後的值,再對這個欄位 index。

第三個是講 defrag 的事情,這部份 MySQL 也可以用第三方的工具 Percona Toolkit 搞定。第四個講 PostgreSQL 的 Write-Ahead Log,有點像是 MySQL 的 binlog。最後一個講 Python 上的 psycopg2

看來看去就是 index 那塊最明顯。可以直接減少去正規化的欄位...

Percona 將辦 Webinar 說明資料庫讀寫分離時的處理...

MySQL replication 通常是資料庫擴充的第一步,因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。

在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar,說明在 MySQL replication 架構下要如何處理讀寫分離。

看起來包括對 replication lag 時的處理 (slave 因為各種原因,導致跟不上 master),有興趣的人可以去報名聽聽看... 雖然是講 PHP,但這個問題在其他的語言也會遇到,聽觀念也應該有幫助。

分散式系統的建言...

「分散式系統」(Distributed System) 是個老詞彙,但跟最近當紅詞彙「雲」、「NoSQL」常常相關。也因此「雲」與「NoSQL」常常遇到的都是分散式系統遇到 (並且討論過) 的問題...

而「Notes on Distributed Systems for Young Bloods」這篇寫的好血淚 XDDD 除了講理論面的東西以外,也把實務面會遇到的問題拿出來講...

首先要先知道「Fallacies of Distributed Computing」,在分散式系統裡,能假設的事情實在太少,要處理的事情太多。而「CAP theorem」也是個必讀的主題,從 Amazon 丟出「Dynamo: Amazon's Highly Available Key-value Store」這篇經典的 paper 後讓更多人知道這個理論。

熟悉上面兩個主題後,接下來就是血淚史... XD

garbage collection pauses make masters “disappear”

啊,GC 讓 master 不見... (NameNode... XDDD)

Writing robust distributed systems costs more than writing robust single-machine systems.

Robust, open source distributed systems are much less common than robust, single-machine systems.

這兩條... XD

Oh, and Paxos really is very hard to implement

Paxos... XD

If you can fit your problem in memory, it’s probably trivial.

(噴飯)

“It’s slow” is the hardest problem you’ll ever debug.

連問題都找不到嗎... XD

撇開這些碎碎念的部份,就算對 distributed system 沒那麼熟,這篇文章也提到了很多「解決的方向」以及「關鍵字」讓你找資料,對於實際操作時會有很大的幫助。

Percona Toolkit 2.1.8 開始支援 Percona XtraDB Cluster (PXC) 與 MySQL 5.6...

Percona Toolkit 是一大包管理 MySQL 的工具套件,裡面有非常多的 script 可以用。雖然有其他家的工具,但目前 Percona Toolkit 的功能算是相當完整,幾乎是必裝套件。

如標題所說的,雖然還是 beta 階段,但最新版的 Percona Toolkit 總算把 Percona XtraDB Cluster (PXC) 與 MySQL 5.6 納入支援:「Percona Toolkit 2.1.8 released today with beta support for MySQL 5.6」。

MySQL 平行執行的 Replication...

MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到,在 5.6.3 之前的版本,MySQL replication 都是 single-threaded,所以當 master 可以充分發揮多 CPU 能力時,slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說,假設 master server 上有兩個 thread 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2,也假定是 CPU bound,也需要跑 100 秒)

假設 thread 1 先執行完,這時候 slave 就會在跑完的時候收到 SQL 1,然後把資料同步進去。等到 100 秒過去後,再跑 SQL 2,再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣:

兩個 SQL query 可以同時跑。

到了 slave 時,在 MySQL 5.6.3 之前的 replication 會變成這樣:

可以看到還是得先執行 SQL 1 再執行 SQL 2,所以最長會有 200 秒的 replication lag。

而 5.6.3 之後支援 multi-threaded replication,可以用 slave_parallel_workers 指定平行執行 SQL query 的數量,這讓 master server 與 slave server 之間的 replication lag 降低不少:

在收到同步的 SQL 指令後就可以同時跑,這讓 replication lag 降到 100 秒。

不過還是要提,如果希望把資料同步問題降到最低,那麼 Galera Cluster 可以解的更徹底,不論是寫入的那台 master server,或是其他的 master server (在 Galera Cluster 架構裡都是為 master),一律都是同步執行:

不會有 master server 與 slave server 不同步的問題,可以減少很多 application 層的麻煩...

看 Mozilla Database Team 的年終報告...

有時候除了可以看介紹新技術的文章學東西外,報告類的文章也可以看得出來目前的趨勢。

像是 Mozilla Database Team 的年終報告描述近況與最後這季做了哪些事情「December News from the Mozilla Database Team」:

  • 之前還在用 MySQL 5.0,現在 Migrate 到 5.1 了,另外正在嘗試 MariaDB 5.5。
  • 很大一部分是在 tune Bugzilla 的效能,包括 SQL query optimization,以及 data partition 計畫。
  • 測試 SSD 覺得不錯,看起來好像也測過 Fusion-io 的產品,不過價錢不太能接受?

另外還有一些 PostgreSQL 的說明,看起來還沒穩下來...

目前已經看到維基百科與 Mozilla 都在嘗試 MariaDB,看了看 MariaDB versus MySQL - Features 發現有趣的東西還不少,除了 Aria 以外,Virtual ColumnsDynamic columns 似乎都是有趣的東西...