內容是本週公司內部技術訓練的記錄。

上週公司內訓有談到基本的資料庫擴展之道，其中包括 Replication, Sharding 及 Cluster。爾後，讓同事自行抽空瞭解，一週後再回頭討論會更有想法。因此，本週內訓重點自然落在深入淺出資料庫擴展之道。

今日談及：

  • Replication, Sharding 及 Cluster 三者間的主要差異。
  • Data Consistency Policy 的種類、優缺點，及對 Replication, Sharding 及 Cluster 的影響。
  • Connection Pool 的用途及功能；而且 PHP 要做到也行，只是 Connection Pool 其實也有他的缺點，不做有時會比較保險。
  • PHP mysqlnd / mysqlnd_ms / mysqlnd_qc 的介紹，以及與 Replication, Sharding 及 Cluster 三者間的關係為何，又有何助益。
  • Cluster 的工具：MySQL Cluster 及 Galera Cluster 的優缺點為何，什麼情況下應該用哪個。
  • Sharding 的工具：MySQL Fabric 的優缺點為何，自己做的話又應該如何實現。
  • Replication 的工具：MySQL Replication, MySQL Async Replication, MySQL Semi-sync Replication, Schooner Active Replication, Tungsten Replicator 及 DRBD 的優缺點為何。
  • 介紹公司各產品線的資料庫設計，說明為何我當初這麼設計的原因。要如何設計出一個資料庫結構，可符合未來 Replication, Sharding 及 Cluster 的要求，讓升級痛點有效降低。

舉例來說，若採用 Replication 時，在大多數情況下，我都不建議使用 DRBD。

  1. 目前 DRBD 僅適合資料庫僅有兩台的環境。限於兩台的要求將限制未來的擴展能力。
  2. 雖然 DRBD 支援 3 台以上資料庫，但請看附圖。一來，DRBD 會依資料庫數量增加而愈趨複雜 (圖中有三台資料庫，卻要啟用四個 DRBD；若增為四台資料庫，則要六個 DRBD)；二來，愈多的 DRBD 會導致 downtime 愈長，影響服務恢復的能力 (DRBD 的樹狀結構使得主節點至尾節點的路線拉很長)。
  3. 其他 DRBD 的缺點，我就跳過不說了。

img