在 PostgreSQL 上用 GPU 加速計算...

看到 PGStorm 這個 PostgreSQL 上的惡搞套件,可以把本來 CPU 要做的事情丟到 GPU 上加速...

不過例子很怪啊,不是用 R-tree index 解決的事情嗎?PostgreSQL 明明就有支援 R-tree index 啊?為什麼會要這樣設計,然後用 table scan?我再回去想想好了...

判斷資料庫是否可以轉移到 Galera Cluster 上的方式...

Open Query 的人給了一個很簡單的方式,只要下一個 SQL query 去查就可以知道有哪些 table 不符合 Galera Cluster 的條件:「Galera pre-deployment check」。

就目前看到的說明以及 SQL query 算是 pre-check:回報 okay 不代表上了就沒問題,但如果有回報有問題,表示上了 Galera Cluster 後會遇到問題。

這個檢查適用於 MySQL 以及目前常見的 MySQL fork (像是 MariaDBPercona Server)。

MySQL 5.7...

Oracle 的「MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7」列出 MySQL 5.7 預定會有的功能。由於還在發展階段,這頁還會繼續變動。

針對 ALTER TABLE 有不少改善,以下的條件下 ALTER TABLE 將不會產生 temporily table (不會卡住):

  • table 改名。
  • column 改名。
  • column 改 default value。
  • enum 或 set 在不修改原來值的情況下增加值。
  • partition 相關操作。
  • index 改名。
  • index 新增與刪除。(僅限 InnoDB)

幾個常見的操作變得更簡單了,pt-online-schema-change 的功能會慢慢被整合回 MySQL。

然後 InnoDB 要支援 spatial data types 了,不過 index 還沒支援... 不知道有沒有機會看到 :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 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 的時候改變的,不過作者蠻意外沒什麼人提到...

InnoDB 的 Table Lock

InnoDB 設計上允許同時讀寫,在大多數的情況下不會產生 table lock,不過還是有機會。(或是刻意產生)

在「Innodb Table Locks」這篇文章提到 InnoDB 的各種 lock (都是帶過而已,不過當關鍵字去 Google 找應該是夠用了),在文章最後面整理出結論,第一個是:

MySQL Table level locks and Innodb Table Level locks are two separate beings.

而就算是 InnoDB,你也還是可以用 LOCK TABLES,效果的確會如同你想的,只是這並不是由 InnoDB engine 實作。而最後是這樣建議:

It is a good practice not to use LOCK TABLES when you're using Innodb Tables.

另外註解也有提到 auto inc primary key 偶而也會造成問題,都可以當關鍵字去找出細節 :p

Reply to「長野雅廣 (Masahiro Nagano) 的 MySQL Beginners Talk」的 comment :p