在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決:「MySQL High Availability: Stale Reads and How to Fix Them」,另外在留言也有人提到 Booking.com 的解法:「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下,最簡單的擴充方式是架設 slave server,然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split),但因為 MySQL 的 replication 是非同步的,所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料,也就是 replication lag。

這就大概有幾種作法,一種是當發現 lag 時就回 master 讀,但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看,但這個方法就不保證讀的到東西,因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境,預設還是 R/W split,但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性,在寫入時多寫一份資料,然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法,其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊,然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法,不知道各家 framework 對這些方式的支援度如何...

Amazon Aurora Global Database

AWSAurora (MySQL) 推出 Amazon Aurora Global Database:「Announcing Amazon Aurora Global Database」。

看起來不是 multi-master (從 secondary region 這個字看),所以寫入的部分還是得送回 primary region 處理:

Aurora Global Database uses storage-based replication with typical latency of less than 1 second, using dedicated infrastructure that leaves your database fully available to serve application workloads. In the unlikely event of a regional degradation or outage, one of the secondary regions can be promoted to full read/write capabilities in less than 1 minute.

應該是單一 endpoint 幫你處理這些雜事...

CloudFront 十週年、在東京的第十個 PoP,以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了,另外這次在東京又加節點了,變成 10 個:「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket:「Amazon CloudFront announces support for the WebSocket protocol」,以及支援 Origin Failover:「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能,大家主要是希望利用 CloudFront 擋 DDoS,正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin,當主要的掛掉時可以切到備用的,對於支援多節點的架構算是第一步 (目前看起來只能設兩個):

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度?

在家裡 (???) 建立 HA 的網路環境...

Brad Fitzpatrick 在他家裡弄的 HA 架構,對一般人來說是有點誇張了 (看起來主要還是玩得開心),但對網路公司來說是個可以參考的方式,降低網路與設備故障帶來的業務衝擊... 先前在弄辦公室連外網路時也有弄過類似的架構,還蠻有趣的。

然後發現原來西雅圖的電這麼便宜,一度大約 NTD$3:

The whole setup including all APs and switches draws about 220 watts idle. Power is pretty cheap in Seattle. Washington State (as of April 2018) has the cheapest electricity in the United States, at $0.0974/kWh.

其他技術的東西反而是看看而已 XD

EC2 的 Dedicated Instance 也支援 Auto Recovery 了...

所以除了一般的 EC2 instance 可以設定 Auto Recovery 外,實體機的 Dedicated Instance 也可以設定了:「Amazon EC2 Auto Recovery is now available for Dedicated Instances」。

不過能用架構做 High Availability 還是用架構做會比較好 (像是透過 ELB 擋在前面提供服務),Auto Recovery 因為是透過 CloudWatch 偵測 (目前最短的偵測時間應該是 10 秒一次),再加上要等新機器接手,還是會有明顯的 downtime。

Avast 放出他們的 Decompiler,RetDec

AvastMIT License 放出他們的 Decompiler,叫做 RetDec:「Avast open-sources its machine-code decompiler」,專案在 GitHub 上的 avast-tl/retdec 這邊。

Decompiler,也就是直接把 machine code 試著轉回高階語言的程式碼:

這對於分析工作來說簡化很多,尤其是在資安產業的人... 以往比較常見是轉成 assembly 再用人工分析,現在這樣有機會讓大腦輕鬆一些。

雖然目前有些限制 (像是 32 bits only),不過 open source 出來後,可以預料會有不少人開始加功能進去:

  • Supported file formats: ELF, PE, Mach-O, COFF, AR (archive), Intel HEX, and raw machine code.
  • Supported architectures (32b only): Intel x86, ARM, MIPS, PIC32, and PowerPC.

Cloudflare 新推出的 Geo Key Manager

Cloudflare 對新推出的 Geo Key Manager 寫了兩篇文章說明:「Introducing the Cloudflare Geo Key Manager」、「Geo Key Manager: How It Works」。

這個服務是之前推出的 Keyless SSL 的延伸應用。

Keyless SSL 是將 Private Key 放在自己家,透過加密協定讓 Cloudflare 使用 (有點像是 HSM 的概念,也就是 Hardware security module,不讓應用的人存取到 Private Key)。這次推出的 Geo Key Manager 則是取中間值,希望針對效率與 High Availability 做出改善。

改善的方法還是將 Private Key 上傳到 Cloudflare 裡,但不是 Cloudflare 所有的機房,而是讓使用者挑選某些風險比較低的地區。

像是只放在美國,或是只放在歐盟,或是以安全度來選擇:

這其實是不信任政府單位而設計出來的系統,雖然效果如何還不知道...

Python 在高收入國家的成長

Stack Overflow 的內文其實有點奇怪的誤導... 主要是分析在 Stack Overflow 上 Python 成長的趨勢:「The Incredible Growth of Python」。

但一開始的分析是做高收入國家的部份:

但如果你捲到最下面,即使是非高收入的國家也是一樣急遽成長,只是沒那麼明顯:

Anyway,回到高收入國家的部份,如果用模型預測的話:

另外列出 YoY 成長:

這篇用高收入這個分法有種在炒話題的感覺...

AWS CloudWatch 推出秒級的記錄功能

AWS CloudWatch 推出了秒級的記錄功能:「New – High-Resolution Custom Metrics and Alarms for Amazon CloudWatch」。

從一分鐘變成一秒鐘讓之後的調整以及 debug 好用很多... 不過這次支援秒級的是 custom metrics,原先 AWS 自家服務的支援不在這次範圍:

Today we are adding support for high-resolution custom metrics, with plans to add support for AWS services over time. Your applications can now publish metrics to CloudWatch with 1-second resolution.

另外 alarm 的時間可以降到十秒:

You can watch the metrics scroll across your screen seconds after they are published and you can set up high-resolution CloudWatch Alarms that evaluate as frequently as every 10 seconds.

對於市場上一堆服務的衝擊應該不小 XD

DigitalOcean 推出 High CPU Droplets

DigitalOcean 推出了高 CPU 使用量的 VPS 服務:「Introducing High CPU Droplets」。

價位從 USD$40/month 開始。相較於 Standard Droplet,CPU 的速度提升到 2.5 倍速 (平均):

The current CPUs powering High CPU Droplets are the Intel Broadwell 2697Av4 with a clock speed of 2.6Ghz, and the Intel Skylake 8168 with a clock speed of 2.7Ghz. Customers in our early access period have seen up to four times the performance of Standard Droplet CPUs, and on average see about 2.5 times the performance.

目前早期先開放這些區,八月底會開 FRA1 與 LON1:

These Droplets are available through the Control Panel and the API starting today as capacity allows in SFO2, NYC1, NYC3, TOR1, BLR1, and AMS3. They will be available in FRA1 and LON1 by the end of August.

等 benchmark 數字出來後才會比較清楚跟 AWS 上的 c4.large 系列比起來如何... 不過現在看起來 DigitalOcean 想直接跟 AWS 對決?如果技術上沒有特別的東西,應該會蠻辛苦的... (因為只剩下價格)