Percona 的 MySQL 5.6...

剛剛看到 Percona 放出第三個基於 MySQL 5.6 的版本了,仍然是 alpha 等級 (還在測試階段):「Announcing Percona Server for MySQL 5.6.10-60.2」。

這也是 MySQL 5.6 進入 GA 後 Percona 推出的第一個版本,而且剛剛看 Percona 的文件網站也發現建出來了:「Percona Server 5.6 - Documentation」。

Percona XtraDB Cluster 目前還是基於 5.5 的版本,不知道 Codership (Galera Cluster 的開發公司) 有沒有打算換新...

MySQL 5.6 的 GTID...

看到 Percona 的人在討論 MySQL 5.6 的 GTID (Global Transaction ID) 功能,剛剛就實際到 AWS 上開了兩台 m1.large 測試:「How to create/restore a slave using GTID replication in MySQL 5.6」。

要測試 GTID,因為剛出來沒多久,沒有多少文件可以看。MySQL 官方的「Replication with Global Transaction Identifiers」是必讀的文件。查 MySQL 官方文件時可以發現 5.6.9 (RC) 到 5.6.10 (GA) 其實還是改了不少變數名稱,如果在網路上找舊文章照抄是不會動的...

先提結論,Galera Cluster 畢竟出來很久了,成熟度比 GTID 高,建議現在先觀望一陣子,至少等 best practice 出來後再進場測試...

之前的 MySQL replication 有很多方法可以在不停機,或是停的時間很短的情況下把第一份 slave 資料與 replication 資訊生出來,舉例來說:

  • 系統如果用 InnoDB,可以用 Percona Xtrabackup 拉出。
  • 系統如果用 XFS + LVM,可以用 FLUSH TABLES WITH READ LOCK + XFS freeze + snapshot 功能拉出。
  • 甚至直接用空的 slave 跑 pt-table-sync...

但目前 MySQL 官方對 GTID 給的方式是 read only + mysqldump,這就算用 xtrabackup 也應該快不到哪吧... 這幾個月應該會一直有文章出現,裡面應該會有偷吃步的方法,看到再來測試看看 :o

跳過 MySQL replication 失敗的方法...

MySQL replication 發生錯誤後,需要一邊 skip replication error,一邊跑 pt-table-sync 強制資料庫同步:

while true; do ( echo 'SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;' | mysql -h $1 ) || sleep 1; done

那個 sleep 1 的設計是用在「如果 replication 正常,停一下再跑一次」的前提下而設計的;如果不需要的話拿掉也是 okay 的。

要注意,能這樣跑的前提是 max_connect_errors 要開超大,我是設成 max_connect_errors = 4294967295

熱 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"

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 的時候改變的,不過作者蠻意外沒什麼人提到...