MySQL 5.6 到 5.7 改變的預設值

Percona 整理了一份 MySQL 5.6 到 5.7 改變的預設值,對於評估與轉移的人都很有用:「MySQL Default Configuration Changes between 5.6 and 5.7」。

sync_binlog 居然從 0 改成 1 了,這對效能的影響應該不少。

performance_schema_* 有不少改成自動調整了,可以省下不少功夫。

innodb_buffer_pool_dump_at_shutdowninnodb_buffer_pool_load_at_startup 都打開了,這避免了正常重啟時的 warm up 問題,不過在存在有效的手段可以手動 warm up 的時,應該還是會關掉吧。(參考 2013 的文章「熱 MySQL InnoDB 的方式...」)

另外介紹了 InnoDB 預設格式的改變,這點到是因為使用 COMPRESSED,反而不太受到影響。

設計資料同步問題時一定會遇到的 Conflict 解決方案

在「A Conflict-Free Replicated JSON Datatype」這邊看到有趣的東西。(arXiv 說 2016/08/18 會有一個小時的 downtime,台灣時間剛好是 2016/08/18 的 20:20 開始:「Maintenance scheduled for Aug 18 8:20 a.m. EDT」)

作者們設計這個架構是想要在 JSON 結構上找出一個演算法,在 P2P 架構上 (而不需要靠 server) 可以同步並且產生一致的結果,另外要求當 conflict 時不要掉資料:

In this paper we present an algorithm and formal semantics for a JSON data structure that automatically resolves concurrent modifications such that no updates are lost, and such that all replicas converge towards the same state.

作者提出來的想法不是很複雜,而且 merge 保留姿的方法也頗... 特別,但總是給大家一個想法,各何況很多情況下都是有 server 架構,就簡單多了...

Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西:

用 Syncthing 同步檔案 (取代 Dropbox 與 BitTorrent Sync)

最早的時候是用 Dropbox 同步檔案,但 Dropbox 的空間有限,加上有不少隱私疑慮,後來只拿他放一些簡單的東西... (像是「世界迷霧」的匯入功能)

然後前陣子則是用 BitTorrent Sync,不過 Sync 2.0 版強制要 trial:「Disable Pro Trial In Sync 2.0?」,後來就決定找替代品了。

這次找的替代品是用 Go 寫的 Open Source 的方案:Syncthing,常用的幾個平台都有支援,包括 Windows、Mac 以及我自己平常用的桌機環境 Linux

先講概念性的部份,Syncthing 的架構與其他同步軟體不太一樣,最大的差異在於兩邊都需要輸入 Device ID 才能建立連線。另外目前 GUI 的部份只有支援 WebUI,像這樣:

在安全性的部份,Syncthing 則是使用 3072 bits 的 RSATLS 1.2 建立連線,Device ID 則是用 Public Key 產生出 SHA-256 的值再用 Base32 表示 (所以看起來很長)。(參考「Understanding Device IDs」以及「Block Exchange Protocol v1」)

也因為使用 TLS 1.2,所以傳輸時必須有一邊是可以接受連線的,而 Syncthing 目前有支援 UPnP,所以大多數家用的 NAT 環境應該是沒問題。

安裝的部份,Ubuntu 可以透過 APT 安裝並且跟著更新,Windows 目前看起來是把 zip 抓下來丟著比較麻煩一點,不過還可以接受。

另外常見到的功能是希望開機時自動啟動。可以參考官方寫的「Starting Syncthing Automatically」這篇,令外 Windows 上可以參考「SyncthingTray」這個工具。

大約用了一個禮拜,目前用起來還不錯...

Bitcoin 電子錢包的初始化加速

因為從以前到現在的歷史記錄都被累積起來,Bitcoin 電子錢包初始化所需要的時間變得很長,所以就有不少方法想要改善。

在「Bitcoin Blockchain Initial Sync Time Dramatically Reduced By Headers-First Sync」這篇文章裡面提到了一些事情。

目前的歷史記錄大約是 22GB,文章裡說平均是兩天可以跑完 (我自己是跑了五天...),但另外一個方法則是可以透過「[ANN] Bitcoin blockchain data torrent」這邊提供的 BitTorrent 方式下載記錄 import 進去,這樣就有機會縮短到 4 小時。

另外被提出來的方案是減少傳輸量先確認。而且這個方法已經被 merge 進官方的 client 了:「Headers-first synchronization」,過陣子來測看看速度如何...

利用 pt-online-schema-change 同步 master 與 slave 的資料

在「Syncing MySQL slave table with pt-online-schema-change」這篇看到 master 與 slave 的資料不同步時,強制性同步的方法:

pt-online-schema-change --alter 'ENGINE=INNODB' D=dbname,t=tblname

由於 pt-online-schema-change 的作法是建一個新的表格,然後把舊表格的資料寫過去,而這些行為會被 replicate 到新機器上,於是就同步了...

這招有趣 XDDD

用 pfSense 架設 Firewall (以及 NAT)

pfSense 是一套很不錯的 firewall 以及 NAT 服務,上面還可以跑一切服務 (像是 OpenVPN 或是 Squid),不過後來都是用商用的硬體方案來處理...

看到「Build your own pro-grade firewall」這篇突然想到要查 pfSense 是否可以 High Availability,如果做的夠好的話,其實可以用兩台機器來跑,成本相對低很多。

結果查到這篇官方文件「Configuring pfSense Hardware Redundancy (CARP)」,裡面有幾個關鍵字,像是 XMLRPC Sync 似乎暗示了設定也可以同步?

官方文件裡的配置圖。

該測試看看了,兩台 server 也才十萬,但兩台能跑到 500Mbps+ 的硬體防火牆的價錢就貴多了... (不過比較省電?)

Percona XtraDB Cluster 5.5.33-23-7.6...

Percona XtraDB Cluster (Galera Cluster) 出新版:「Percona XtraDB Cluster 5.5.33-23.7.6 is now available」。

看到了幾個比較特別的功能:

Desync functionality has now been exposed to the client. This can be done either via /*! WSREP_DESYNC */ comment on the query or by setting the global wsrep_desync variable to 1.

這個功能感覺上是打算為了在 Percona Toolkit 裡面配合 pt-table-sync 而準備的?

另外一個重要的功能是限速,這可以避免在伺服器最忙碌的時候加重負擔造成伺服器撐不住:

Percona XtraDB Cluster has implemented new rate limiting, rlimit, option for XtraBackup SST that can be used to avoid saturating the donor node.

以往我是自己 patch 一個 shell script 出來用,現在則變成是原生支援,那麼本來的 patch 方式就要轉換到原生支援上...

然後文末有建議 Debian 使用者在升級前要先安裝 socat,避免升級發生問題 :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