Citus 總結：高可用

  1. Citus 的複製功能

前面有提到，Citus 支持兩種數據複製方案：

爲什麼會同時存在兩種方案呢？可以看看 Citus 複製功能的演進過程。

1.1 第一階段：客戶端複製 DML 語句到多個 Worker 節點

在早期的版本中，Citus 的主要應用場景是實時數據分析場景，用戶批量的導入數據，並通過 Citus 進行實時數據查詢分析，數據不需要修改，是完全 Append-only 的場景。

Append-Only 的場景，各分片數據只需要在完成導入後是一致的就行，爲了最大化導入性能，可以從客戶端直接並行導入。

這個階段，Citus 導入數據的流程如下：

1.2 第二階段：Coordinator 複製 DML 語句到多個 Worker 節點

隨着使用 Citus 的人越來越多，對於提供數據更新能力的需求也越來越多。爲了提供數據更新能力，Citus 需要解決兩個主要的問題：

爲了解決引入數據更新能力的問題，Citus 將更新操作集中到了 Coordinator 節點，由集中的 Coordinator 節點處理併發衝突和故障處理。

此時，數據的多副本複製，改成了由 Coordinator 節點複製 DML 語句到多個 Worker 節點執行。

1.3 第三階段：推薦使用 Streaming Replication

隨着使用 Citus 的場景增加，例如多租戶的場景，Citus 引入了 Co-located 親和性共存能力，可以把相同租戶的數據親和性存儲在同一個 Worker 節點，方便支持 Join 查詢，Rollup、外鍵約束等特性。

此時，前面基於複製 Statment 的複製方案就會碰到問題，當某個 Shard 因爲短時故障被標記爲 invalid 時，應該如何處理處於同一個 Co-located 親和組的其他 Shard？

這是一個兩難的問題，爲了安全起見，Citus 在 6.0 版本中把複製因子的默認值從 2 改爲了 1，就是因爲多租戶場景下可能會產生違反外鍵約束的問題。

現在，Citus 推薦的是使用 PostgreSQL 的 Streaming Replication，如下圖所示，Streaming Replication 是 primary-based replication，由主節點解決併發控制問題。

  1. 雲上 Citus 高可用備選方案

2.1 備選 1：Streaming Replication

如前面描述，Streaming Replication 是 PostgreSQL 的內置特性，通過將 WAL 記錄持續複製到 Standby 節點，建立 Hot Standby 備份節點。

2.2 備選 2：鏡像卷

在雲上，也可以使用雲提供商的鏡像卷能力，當 Primary 節點故障時，在對應備份卷的主機上拉起數據庫進程接管業務。

2.3 備選 3：從日誌恢復

如果對 RTO 業務恢復時間不太敏感，也可以採用將 WAL 日誌增量備份到對象存儲的方式，本方案的成本更低，故障後，拉起對應計算節點，從對象存儲恢復日誌並重放數據即可。

2.4 備選方案對比

2.5 Azure Hyperscale(Citus) 的高可用方案

Coordinator 節點和 Worker 節點都使用 Streaming Replication 方案將數據同步複製到位於另一個 AZ 的 Standby 節點，支持 AZ 級的容災。主要技術指標有：

參考

https://www.citusdata.com/blog/2016/12/15/citus-replication-model-today-and-tomorrow/

https://github.com/citusdata/citus/issues/998

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/a_ctXHVwNtTQ0qG4cAaM8g

猜你喜歡