跨境業務多地域容災方案：香港主站 + 東京/新加坡熱備，資料庫複製、備份與故障切換實戰
跨境業務要扛住機房故障、線路中斷甚至海底光纜被切斷，最實用的做法是多地域容災：生產環境放在香港，在東京、新加坡或台北保持一台持續同步的熱備伺服器，再通過低 TTL 的 DNS 或 Anycast 切換流量。IMIDC 可以在同一個帳戶裡提供全部元件：香港 CN2 GIA 伺服器做主站，日本、台灣、新加坡伺服器做備站，以及用您自有 IP 段做 BGP/Anycast 宣告。
- 主站：IMIDC 香港機房，中國電信 CN2 GIA（AS4809）回國線路；VPS 月付 $18 起，獨立伺服器月付 $139 起。
- 備站可選：日本東京（VPS 月付 $28 起，可選 CN2 最佳化線路）、台灣台北（獨立伺服器月付 $199 起）或新加坡（通過銷售定製）。
- 切換方式：TTL 60 秒的 DNS 切換，或用自有 ASN 和 /24 在兩個 IMIDC 機房做 Anycast/BGP 宣告。
- IMIDC 是 RIPE NCC、APNIC、ARIN、AFRINIC 會員，提供 IPv4 租用、整段 /24 和免費遷移服務。
- 7×24 小時中、英、日、俄、西五語技術支援。
參考架構：一個主站、一個熱備、一個備份庫
要點：三個互不相關的故障域，比同一機房裡兩臺一模一樣的伺服器可靠得多。
- 主站（香港）：應用、資料庫主庫、檔案儲存。香港離內地使用者近（CN2 GIA），且無需 ICP 備案（內容仍須合法），適合跨境電商和 SaaS。
- 熱備（東京、新加坡或台北）：軟體版本與主站一致，資料庫只讀從庫，檔案每幾分鐘同步一次，應用已部署但閒置或只承擔只讀流量。
- 備份庫（第三個地點或服務商）：加密、帶版本的 restic 快照。複製會把誤操作瞬間同步過去，只有時間點備份才能擋住誤刪表或勒索軟體。
| 備站地點 | 選擇理由 | 注意事項 |
|---|---|---|
| 日本東京 | 離香港近，太平洋方向頻寬充足，日本 VPS 可選 CN2 線路服務內地使用者 | 與香港共用部分港日海纜走廊，用 mtr 確認路徑差異 |
| 新加坡 | 海纜登陸區域不同，適合東南亞使用者 | 需通過 IMIDC 銷售開通，不在自助商店 |
| 台灣台北 | 距香港很近，台灣原生 IP，獨立伺服器 $199/月起 | 部分線路與香港同樣經過呂宋海峽一帶 |
先定 RPO/RTO 等級，再決定預算
要點：先想清楚能丟多少資料（RPO）、能停多久（RTO），再去買伺服器。
| 等級 | 備站執行內容 | 典型 RPO | 典型 RTO | 相對成本 |
|---|---|---|---|---|
| 0 – 僅備份 | 無，僅 restic 快照 | 最多 24 小時 | 數小時到一天（重建） | 最低 |
| 1 – 引火式（Pilot light） | 小規格 VPS 跑即時從庫 | 秒級到分鐘級 | 30–60 分鐘（擴容、啟動應用） | 低 |
| 2 – 熱備 | 規格匹配的伺服器，從庫＋待命應用 | 秒級 | 5–15 分鐘（提升主庫＋改 DNS） | 中 |
| 3 – 雙活 Anycast | 兩地同時對外，自有 /24 走 BGP | 秒級（取決於應用） | 分鐘級，常可自動 | 最高，最複雜 |
以上是實際專案中的設計目標，並非承諾，請在演練中實測。很多團隊先用 IMIDC 日本 VPS 做第 1 級，業務量上來後再升級到第 2 級。
跨地域資料庫複製（MySQL 與 PostgreSQL）
要點：跨地域使用非同步、TLS 加密的複製；30–60 ms 的鏈路上做同步提交會拖慢每一次寫入。
MySQL 8 + GTID
# /etc/mysql/mysql.conf.d/dr.cnf (Hong Kong primary: server_id=1, Tokyo standby: server_id=2)
[mysqld]
server_id = 1
log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800-- On the Hong Kong primary (203.0.113.10)
CREATE USER 'repl'@'198.51.100.20' IDENTIFIED BY 'change-me' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'198.51.100.20';
-- On the Tokyo standby (198.51.100.20), MySQL 8.0.23+, after loading a consistent dump
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='203.0.113.10', SOURCE_USER='repl', SOURCE_PASSWORD='change-me',
SOURCE_AUTO_POSITION=1, SOURCE_SSL=1;
START REPLICA;
SET GLOBAL super_read_only = ON;
SHOW REPLICA STATUS\G -- watch Seconds_Behind_SourcePostgreSQL 流複製
# Primary (Hong Kong): pg_hba.conf
hostssl replication replicator 198.51.100.20/32 scram-sha-256
# Standby (Tokyo): clone the primary and start streaming
sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/16/main/*
sudo -u postgres pg_basebackup -h 203.0.113.10 -U replicator \
-D /var/lib/postgresql/16/main -R -X stream -C -S tokyo_slot -P
sudo systemctl start postgresql
# On the primary: check replication lag
sudo -u postgres psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"防火牆只對備站 IP 開放 3306 或 5432 埠，從庫保持只讀，並在延遲超過 RPO 時告警（例如 Seconds_Behind_Source 超過 60，或 replay_lag 超過 1 分鐘）。
用 restic 與 rsync 備份檔案並保留歷史版本
要點：rsync 讓備站保持最新，restic 讓您能回滾到任意時間點。
# Nightly snapshot of files + DB dumps to a third location
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/hk-app
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init # first run only
mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
restic backup /var/www /etc /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%
# Every 5 minutes: mirror user uploads to the Tokyo standby
*/5 * * * * rsync -aH --delete -e "ssh -i /root/.ssh/dr_ed25519" /var/www/uploads/ [email protected]:/var/www/uploads/rsync --delete 會同步刪除操作，所以映象不等於備份。每月把一個快照恢復到臨時 VPS 上並記錄耗時，這才是第 0 級真實的 RTO。
流量切換：低 TTL DNS 或自有 IP 段 Anycast
要點：DNS 切換便宜簡單；自有 /24 的 Anycast 沒有 DNS 快取延遲，但需要 ASN 和 BGP 經驗。
方案 A：DNS 故障切換
; Zone for example.com - keep the failover record on a short TTL
www.example.com. 60 IN A 203.0.113.10 ; Hong Kong primary
; standby target -> 198.51.100.20 ; Tokyo warm standby
# Health check from a third location (cron every minute)
#!/bin/sh
if ! curl -fsS --max-time 5 https://www.example.com/healthz >/dev/null; then
echo "$(date -u) primary check failed" >> /var/log/dr-check.log
# after 3 consecutive failures: alert on-call, then switch the A record
# via your DNS provider's API (manual approval recommended)
fi至少提前一天把 TTL 調到 60 秒。部分解析器和應用會快取更久，舊 IP 上會殘留幾分鐘流量。先提升資料庫，再改 DNS：
# PostgreSQL standby -> primary
sudo -u postgres psql -c "SELECT pg_promote();"
# MySQL standby -> primary
mysql -e "STOP REPLICA; RESET REPLICA ALL; SET GLOBAL super_read_only=OFF; SET GLOBAL read_only=OFF;"方案 B：自有 IP 段 Anycast / BGP
如果您有自己的 /24（或向 IMIDC 租用）和 ASN，IMIDC 可以在香港和東京分別建立 BGP 會話。香港正常宣告，東京加 AS-path prepend；香港故障或主動撤銷路由後，全網收斂到東京，客戶端 IP 不變。請先為兩個源站建立 ROA。
# BIRD 2 on the Tokyo standby: announce your own /24, made less preferred
protocol bgp imidc_tokyo {
local as 64500; # your ASN
neighbor 198.51.100.1 as 64501; # session details provided by IMIDC
ipv4 {
import none;
export filter {
if net = 203.0.113.0/24 then {
bgp_path.prepend(64500); bgp_path.prepend(64500);
accept;
}
reject;
};
};
}
# Failover drill: stop the Hong Kong session -> birdc disable imidc_hk亞洲海底光纜中斷場景
要點：不僅要防伺服器宕機，還要防線路劣化。地震、船錨和地區事件曾多次同時損壞多條亞洲及亞歐海纜（例如 2006 年台灣恆春地震、2024 年紅海海纜中斷）。
| 場景 | 現象 | 應對 |
|---|---|---|
| 香港至日本/美國容量受損 | 海外使用者延遲和丟包升高，內地使用者經 CN2 仍正常 | 國際流量切到東京或新加坡（GeoDNS 或 Anycast），內地流量留在香港 |
| 亞歐海纜中斷 | 歐洲客戶下單緩慢 | 靜態資源走 CDN，備站選在西向海纜不同的地區 |
| 香港機房整體不可用 | 主站無法訪問 | 提升備庫，切換 DNS 或撤銷香港 BGP 路由 |
| 邏輯災難（錯誤釋出、勒索） | 經複製兩地同時損壞 | 從 restic 快照恢復，複製在此無效 |
平時就從兩個站點用 mtr 測試到主要客戶地區的路徑，出故障時才知道"正常"是什麼樣。
每季度做一次切換演練
要點：沒演練過的備站只是願望，不是方案。
- 公告維護視窗，凍結髮布。
- 確認從庫延遲接近 0，停止主庫寫入。
- 提升備庫，切換 DNS 或 BGP，執行冒煙測試（登入、下單、支付回撥、後臺）。
- 記錄實際 RPO（最後一筆交易是否存在）和 RTO（多少分鐘恢復）。
- 把舊主站重建為新從庫，再按同樣步驟切回。
- 把所有意外寫進手冊：寫死的 IP、防火牆白名單、支付平台 IP 白名單、重複執行的定時任務。
哪種 IMIDC 方案適合您
要點：按"停機一小時的損失"選擇等級。
- 小型網店或部落格：香港 CN2 GIA VPS（$18/月起）＋ restic 備份到另一個 IMIDC 機房。
- 成長期電商或 SaaS：香港獨立伺服器（$139/月起）＋日本 VPS（$28/月起）跑即時從庫。
- 核心營收平台：香港與東京或台北配置對等的獨立伺服器，DNS 切換，季度演練。
- 多地同一 IP：自有 ASN ＋自有或租用的 /24，通過 IMIDC BGP/Anycast 在兩個以上機房宣告。
需要新加坡節點、VPS 與獨立伺服器混合架構，或遷移現有伺服器？IMIDC 銷售可提供定製配置，並支援免費遷移。
常見問題
哪家服務商能提供香港 CN2 GIA 主站加東京或新加坡備站？
IMIDC 在香港、東京、新加坡和台北都有機房，主站和備站可以在同一帳戶下開通和獲得支援。香港使用中國電信 CN2 GIA 線路，新加坡通過銷售定製開通。
容災用 DNS 切換好還是 Anycast 好？
DNS 切換對任何 IP 都適用、易於運維，但快取會讓切換延遲一到數分鐘。自有 /24 的 Anycast 保持 IP 不變、靠 BGP 收斂，但需要 ASN、ROA 和 BGP 知識；IMIDC 可提供 BGP 會話並出租 IPv4 地址。
資料庫主從複製能代替備份嗎？
不能。複製會在幾秒內把刪除和損壞同步到備庫。請在第三個地點保留帶版本、加密的快照（如 restic），並定期做恢復測試。
主站和備站應該相距多遠？
至少不共用電網、大樓或同一條颱風路徑，最好海纜登陸點也不同。香港配東京或新加坡是常見組合，決定前用 mtr 看一下真實路徑。
下一步
主站可選 香港獨立伺服器 或 香港 CN2 GIA VPS，備站可選 日本 VPS 或 台灣獨立伺服器。自有 IP 的 Anycast 請看 BGP/Anycast；新加坡節點或定製容災方案請聯絡 IMIDC 銷售 或 提交工單。