用 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