MySQL 5.6 上線,以及 openSUSE 與 Fedora 對 MySQL 的反擊...

Oracle 正式將 MySQL 5.6 推上線 (GA,General Availability):「Oracle Announces General Availability of MySQL 5.6」。

在官方的「What's New in MySQL 5.6」有列出 MySQL 5.6 的進展。另外在 Percona 的創辦人 Peter Zaitsev 所整理的文章「MySQL 5.6: Improvements in the Nutshell」裡面也整理了一份資料。

在 Oracle 的工程師的 blog 上可以看到不少說明 InnoDB 在多 CPU 環境下的顯著進步,不過我是覺得看看就好... 進步是一定有,但實際用起來通常不會有官方說的那麼多 :p

可以預期不久後 Percona 應該會丟出對應的版本 (至少之前已經有風聲了),到時候就用 Percona 的版本吧。

另外一方面,openSUSEFedora 都已經決定將系統內的 MySQL 改用 MariaDB 代替:

原因的話就不詳細寫了,上面有一些無關痛癢的官方說法。在「Oracle who? Fedora & openSUSE will replace MySQL with MariaDB」報導裡寫的比較直接。

大家對 Oracle 沒什麼好感 (於是 Solaris 的事情又被拿出來婊),可以看到在 mailing list 上對 Oracle 的人酸溜溜的 XD

Percona XtraDB Cluster (PXC) 總算出 5.5.29 版本了...

剛剛看到 Percona XtraDB Cluster 5.5.29-23.7.1 的公告了:「Announcing Percona XtraDB Cluster 5.5.29-23.7.1」。

除了修正 bug 外,有很多是讓設定變得簡單的調整 (變得比較不容易中地雷,或是錯誤訊息比較清楚,而非靠 Google 找到答案),像是:

Variable wsrep_node_name was initialized before the glob_hostname, which lead to empty value for wsrep_node_name if it wasn’t set explicitly. Bug fixed #1081389 (Alex Yurchenko).

Percona XtraDB Cluster would crash when binlog_format was set to STATEMENT. This was fixed by introducing the warning message. Bug fixed #1088400 (Seppo Jaakola).

Percona XtraDB Cluster would crash if the node’s own address would be specified in the wsrep_cluster_address variable. Bug fixed #1099413 (Alexey Yurchenko).

該來安排測試了...

用 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,但這個問題在其他的語言也會遇到,聽觀念也應該有幫助。

資料庫裡的浮點數:MySQL 5.1 到 MySQL 5.5 的差異...

Mozilla 最近在升級 MySQL 採「先建後拆」的步驟,發現用 pt-table-checksum 檢查時不一致:「MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation」。

後來發現,在 MySQL 5.1 (5.1.65-rel14.0-log Percona Server (GPL), 14.0, Revision 475) 的查詢結果是:(Mozilla 的範例)

mysql> select float_field from db.tbl where id=218964;
+-------------+
| float_field |
+-------------+
| 9.58084e-05 |
+-------------+
1 row in set (0.04 sec)

而在 MySQL 5.5 (5.5.28a-MariaDB-log MariaDB Server) 的查詢結果是:

MariaDB [(none)]> select float_field from db.tbl where id=218964;
+--------------+
| float_field |
+--------------+
| 0.0000958084 |
+--------------+
1 row in set (0.24 sec)

最後是讓 pt-table-checksum 把 float/double 欄位忽略掉。在 comment 有人提出來是在 MySQL 5.5.3 的時候改變的,不過作者蠻意外沒什麼人提到...

Percona 說明關於為什麼花這麼多時間修正 MySQL 5.5.28 安全問題...

Percona 的 Stewart Smith 解釋為什麼花這麼多時間才修正這個安全漏洞:「CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)

MariaDB 的人在得知問題後先建立了 MDEV-382 這個 issue,然後建立了 rpl_mdev382.test 這份測試資料,讓其他參與者可以測試手上的 MySQL 是否有問題。

Oracle 在修正問題時並沒有使用 MariaDB 這份測試資料測過 (或是測過但因為種種因素...) 就推出 MySQL 5.5.29,但 MySQL 5.5.29 用 rpl_mdev382.test 測試會失敗,而實際確認發現 Oracle 並沒有把問題解乾淨。所以本來 Percona 預定要使用官方 MySQL 5.5.29 版本為基礎推出 Percona Server 5.5.29 (可以降低 Percona 維護成本),變成將會改用 MariaDB 的 patch。

讓 Percona 的人特地寫一篇出來,看起來對 Oracle 不太爽... XD

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」。

測試 MariaDB 後的一些感想...

Monty Program ABMySQL 的發起人 Monty 在離開 Sun 之後所創辦的公司 (他同時也是 MySQL AB 的創辦人),這家公司目前以 MariaDB 為發展主力。

先說對 MariaDB 目前的看法:暫時還是會用 Percona 所提供的版本,以及 XtraDB (基於 InnoDB 的產品)。

MariaDB 發展的重點在於 Aria storage Engine,但目前的 1.5 版只支援 crash-safe,要到 2.0 才會支援 InnoDB 主要功能,而到了 2.5 才會針對效能調整,看起來要到「能用」必須要到 2.5 之後... (參考「Aria FAQ」的說明)

InnoDB 控制權在 Oracle 手上,XtraDB 控制權在 Percona 手上,而 MyISAM 拿不上檯面。所以 Monty 想要一個控制權在他自己手上的 storage engine...

對於社群來說,因為 XtraDB 還是基於 InnoDB 的分支,所以當 Oracle 從 InnoDB 抽手後大家會擔心 Percona 能夠自己發展到什麼程度。這使得對於 Aria 有所期待,也趁著現在 Oracle 被歐盟盯著不致於做的太明顯趕快發展。

這也可能是 WikimediaMozilla 選 MariaDB 當 slave 測試的原因?當然也有可能只是「看名字比較順眼」之類的原因而選... XD

使用 Percona Toolkit 管理 MySQL...

Percona 在前幾天辦了 Webniar 解釋 Percona Toolkit 要怎麼用 (並且宣傳有多好用 XD):「10 Percona Toolkit Tools Every MySQL DBA Should Know About」。

依照慣例,Percona 在結束後會把投影片與錄影整理後放出來 (也就是上面的連結),如果沒時間的話可以看投影片留個印象,有時間的話可以實際操作看看到底有多好用。

另外在 MySQL Performance Blog 上主講者也整理了 Q&A 的部份也很值得看一看:「Percona Toolkit Webinar followup Q&A」。