MySQL InnoDB 的 OPTIMIZE TABLE 的 Lock

Backend Twhttps://www.facebook.com/groups/616369245163622/posts/2467225396744655/ 這邊看到:

先大概回答一下假設,DELETE 後的空間是可以被同一個表格重複使用的,所以應該是還好,不過離峰時間跑一下 OPTIMIZE TABLE 也沒什麼關係就是了。

裡面提到的「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.7 文件) 以及「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.6 文件) 都有講到目前比較新的版本都已經是 Online DDL 了:(這邊抓 5.6 的文件,有支援的版本資訊)

Prior to Mysql 5.6.17, OPTIMIZE TABLE does not use online DDL. Consequently, concurrent DML (INSERT, UPDATE, DELETE) is not permitted on a table while OPTIMIZE TABLE is running, and secondary indexes are not created as efficiently.

As of MySQL 5.6.17, OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.

文件上有提到會有一小段 lock 的時間,不過一般來說應該不會造成太大問題。

這邊要講的是早期的經典工具 pt-online-schema-change (pt-osc),這是使用 TRIGGER-based 的方式在跑,他的範例就直接提供了一個不需要 Online DDL 支援的版本:

Change sakila.actor to InnoDB, effectively performing OPTIMIZE TABLE in a non-blocking fashion because it is already an InnoDB table:

pt-online-schema-change --alter "ENGINE=InnoDB" D=sakila,t=actor

這在早期的時候還蠻常被拿出來用的,如果還在維護一些舊系統的話還蠻推薦的...

Multithreading 版本 pt-online-schema-change

看起來是個嘗試,Percona 的人試著修改 pt-online-schema-change,讓他可以在 INSERT 時 multi-threading,然後看效果:「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。

可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字,下圖是看相對比率):

如果沒有意外的話應該會有更多的測試,而這些測試沒問題的話,之後的官方版本裡面應該就會有這個功能。

在 Galera Cluster 上的 DDL 操作 (e.g. ALTER TABLE)

Percona 整理了一份關於 Galara Cluster 上 DDL 操作的一些技巧,這包括了 Percona XtraDB ClusterMariaDB 的版本:「How to Perform Compatible Schema Changes in Percona XtraDB Cluster (Advanced Alternative)?」。

在不知道這些技巧前,一般都是拿 Percona Toolkit 裡的 pt-online-schema-change 來降低影響 (可以降的非常低),所以這些技巧算是額外知識,另外在某些極端無法使用 pt-online-schema-change 的情境下也可以拿來用...

裡面的重點就是 wsrep_OSU_method 這個參數,預設的值 TOI 就是一般性的常識,所有的指令都會被傳到每一台資料庫上執行,而 RSU 則是會故意不讓 DDL 操作 (像是 ALTER TABLE) 被 replicate 到其他機器,需要由管理者自己到每台機器上執行。

利用這個設定,加上透過工具將流量導到不同後端的資料庫上,就有機會分批進行修改,而不需要透過 pt-online-schema-change 這種工具。

換 Ubuntu 的字型... (Andada、PT Sans Captian、Hack)

在 HiDPI 4K 螢幕下挑字型的基準跟以往普通 DPI 螢幕完全不同。以往會受到當畫素不夠時的限制,在 HiDPI 下就不需要考慮這點了...

我三不五十就會換個字型用 (換心情),所以之後有可能會再換掉... 這次挑選的基準有三個:

  • 免費可在網路上下載個人使用的。
  • 字的重量要重一些。
  • sans 與 monospace 的字要帶有一點 serif 的感覺。

我把 fontconfig 設定放在 99-local.conf 這邊,有興趣的可以直接拉回去丟到 /etc/fonts/conf.d/ 裡用...

Andada 是拿來定義 sans 的,長這樣:(出自「Andada Font Free by Huerta Tipográfica」)

PT Sans Captain 是拿來定義 serif 的,長這樣:(出自「PT Sans Font Free by Paratype」)

Hack 是拿來定義 monospace 的,長這樣:(出自「Hack Font Free by Chris Simpkins」)

跳過 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