幹壞事是進步最大的原動力
在 Hacker News Daily 上看到這款工具，可以在 Windows 上把拆出多個畫面，並且提供給不同的鍵盤與滑鼠使用：「Universal Split Screen」，而且是 open source 專案 (使用 MIT License)，程式碼在 UniversalSplitScreen/UniversalSplitScreen 這邊。
理論上只要不是太吃資源的遊戲，應該都適合這個方法搞 (從他列出來的遊戲列表看起來，似乎都不會太吃 CPU 與顯卡)。
另外在想是不是也可以拿給其他用途使用，像是 PuTTY 之類的程式？
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 相較於自己架設貴不少，目前知道的單位大多也都還是自己架...
看到 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，讓讀的部份可以打散掉：「New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability」。
讀的部份比較容易 scale (常見的方式是透過 replication 做到)，而現在很多 database framework (包括各類的 ORM framework) 都支援讀寫分離，這個支援對於系統的 scale 來說幫忙頗大。
不過不知道會不會有 replication lag 的問題，我猜是會有...
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 軟體提供 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 給的範例提供了很多設定檔，應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了)，對於有興趣的人應該可以丟人研究？
在「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 出去，需要整理時應該會用到...
MySQL replication 通常是資料庫擴充的第一步，因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。
在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar，說明在 MySQL replication 架構下要如何處理讀寫分離。
看起來包括對 replication lag 時的處理 (slave 因為各種原因，導致跟不上 master)，有興趣的人可以去報名聽聽看... 雖然是講 PHP，但這個問題在其他的語言也會遇到，聽觀念也應該有幫助。