Amazon Aurora (MySQL) 的 Stored Procedure 可以跑 AWS Lambda...

查了資料才發現去年十月 Amazon Aurora (MySQL-Compatible Edition) 就支援用 AWS Lambda 當 stored procedure 了,只是當時只支援 async mode,能做的事情比較有限:「Amazon Aurora New Features: AWS Lambda Integration and Data Load from Amazon S3 to Aurora Tables」。

Now you can invoke Lambda functions directly from within an Aurora database via stored procedures or user-defined functions. Lambda integration allows you to extend the capabilities of the database and invoke external applications to act upon data changes. For example, you can create a Lambda function that sends emails to customers whenever their address in the database is updated.

前幾天發表的則是支援 sync mode,可以等到:「Amazon Aurora with MySQL Compatibility Natively Supports Synchronous Invocation of AWS Lambda Functions」。

Starting with version 1.16, we are extending this feature to be able to able to synchronously invoke Lambda functions.

Use the native function lambda_sync when you must know the result of the execution before moving on to another action.

這解掉了 MySQL 的 stored procedure 一直很殘的問題...

AWS 環境裡面提供 NTP Service 了 (Amazon Time Sync Service)

以前在 AWS 環境裡都要自己架設兩台可以連外的 NTP server,然後將內部機器指到這兩台上,現在可以用現成的了:「Keeping Time With Amazon Time Sync Service」。

服務放在 169.254.169.123

You can access the service via the link local 169.254.169.123 IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.

然後也有提到 leap second 的解法,用的解法是 leap smearing:

Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The 169.254.169.123 clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.

先前 AWS 也有 leap time,但不包括 Amazon EC2 這些系統 (EC2 裡的時間是獨立的),不過還是可以看一下 AWS 處理 leap time 的方式,因為這次 NTP Service 就會拿去用了。

最近一次 leap time 是 2016 年底的「Look Before You Leap – December 31, 2016 Leap Second on AWS」,處理的方式跟 2015 年時的方法還是一樣:「Look Before You Leap – The Coming Leap Second and AWS (Updated)」。

類似於下圖左上角這張的變化:

然後全區開放,都可以用了:

This service is provided at no additional charge and is immediately available in all public AWS regions to all instances running in a VPC.

Amazon EFS 推出 File Sync 服務

先前 Amazon EFS 需要找台機器掛上去再同步 (無論是 EC2 的機器還是透過 VPN 將自己的機器接上去),現在推出可以直接把檔案同步進去的服務了:「Sync Files to Amazon Elastic File System Quickly, Easily and Securely with EFS File Sync」。

不過不是所有提供 Amazon EFS 的區域都有,目前只有 us-east-1us-east-2us-west-2 以及 eu-west-1

EFS File Sync is available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions, with availability in the EU (Frankfurt) and Asia Pacific (Sydney) regions coming in December 2017.

另外這是有費用的,目前有提供的四區都是 USD$0.01/GB。

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+ 的硬體防火牆的價錢就貴多了... (不過比較省電?)