AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing,也就只針對部份 IP range 走進 VPN,其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些,因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器),但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多,算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能:「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少,目前知道的單位大多也都還是自己架...

在 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 支援 Reader Endpoint

Amazon Aurora 支援 Reader Endpoint,讓讀的部份可以打散掉:「New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability」。

讀的部份比較容易 scale (常見的方式是透過 replication 做到),而現在很多 database framework (包括各類的 ORM framework) 都支援讀寫分離,這個支援對於系統的 scale 來說幫忙頗大。

不過不知道會不會有 replication lag 的問題,我猜是會有...

Ubuntu 桌機的 Split DNS

Split DNS 指的是某個 DNS domain 使用另外一組 DNS servers,常用在 Partial Route 的 VPN 上,讓內部網域的 DNS domain 正確的被解出來。一般商業的 VPN Software 都會處理掉這塊,不過有時候還是希望可以自己設定...

Ubuntu 桌機上的 Split DNS 可以透過 Dnsmasq 做到,在我的機器上因為透過 ps awx | grep dnsmasq 可以看到 --conf-dir=/etc/NetworkManager/dnsmasq.d,表示設定的目錄在 /etc/NetworkManager/dnsmasq.d 下,所以我把檔案 mysplit 放到 /etc/NetworkManager/dnsmasq.d 下:

#
server=/mysplit.com/10.1.2.3

然後在 dnsmasq 的 manpage 裡面有提到,SIGUSR{1,2} 是拿來分析用的,而 SIGHUP 不是拿來給你重新讀設定檔用的 XDDD

SIGHUP does NOT re-read the configuration file.

所以就砍掉他,隨便對 NetworkManager 做個動作,就會重新把 dnsmasq 帶起來了,或者重開機也可以... 再跑 dig 查的時候就可以查到資訊了。

MariaDB 讀寫分離的工具:MaxScale

MariaDBMaxScale 軟體提供 MySQL 相容的 proxy interface,可以將後端一群 MySQL server 架構隱藏起來,讓應用程式不需要處理這部份。

Percona 的人則介紹 MaxScale 作為讀寫分離的工具:「High availability with asynchronous replication… and transparent R/W split」。

如果你是用有支援讀寫分離的 ORM (像是 Laravel 中的 Illuminate::Database),由於 ORM library 幫你處理好了,你可以省掉這個工作。

但在其他的情況,像是應用程式沒有原始程式碼,或是只能設一組 server,你就必須透過像 MaxScale 這種軟體來幫你打散負荷量。

Percona 給的範例提供了很多設定檔,應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了),對於有興趣的人應該可以丟人研究?

把 Git commit 切開

在「Split a commit in two with Git」這邊看到有趣的方法:

git rebase -i <oldsha1>
# mark the expected commit as `edit` (replace pick in front of the line), save a close
git reset HEAD^
git add ...
git commit -m "First part"
git add ...
git commit -m "Second part"
git rebase --continue

squash 是把多個 commit 合起來,這個方法是拆開。還沒有 push 出去,需要整理時應該會用到...

Percona 將辦 Webinar 說明資料庫讀寫分離時的處理...

MySQL replication 通常是資料庫擴充的第一步,因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。

在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar,說明在 MySQL replication 架構下要如何處理讀寫分離。

看起來包括對 replication lag 時的處理 (slave 因為各種原因,導致跟不上 master),有興趣的人可以去報名聽聽看... 雖然是講 PHP,但這個問題在其他的語言也會遇到,聽觀念也應該有幫助。