資料庫可以說是應用程式的核心，但關聯式資料庫 (RDBMS) 基於 ACID 設計原則，傳統架構導致在運算能力的擴展上，變得不容易實現。擴充上除了典型的 Scale-up (擴充單一硬體能力) 之外，最常使用的就是 Replication 技術，Replication 泛指資料複製模式，會把資料完整的複製到另一個 MySQL 節點上，這樣的方式並不是分散儲存喔。
目前常使用且成熟的關聯式資料庫，一般官方都會提供 Replication 機制，通常官方內建的 Replication 機制已經很成熟，不像幾年前 Open Source RDBMS 都要自己編譯第三方 Replication 功能，當然也有第三方像是 Percona 這樣的套件。透過 Replication 將資料同步複製到其他主機，可以實現運算的擴充與高可用架構。大部分的資料庫應用情境都是 SELECT 居多，最常用到的就是讀寫分離的「主從架構」，如下圖所示：
主要的 MySql Master 節點負責「讀寫」，寫資料會透過 Binlog Relay 機制，以非同步模式複製 Binlog 到每一台 Slave 執行 (正確一點的說法應該是 Slave 透過 REPLICATION 權限連線到 Master 去抓 Binlog 回來執行)，運作時就好像讓 Slave 與 Master 進行資料同步。一般來說，Slave 不提供寫入功能，只負責分散 SELECT 運算，這也是最典型的擴充架構。實作時有一個地方很麻煩，就是應用程式必須自行實作「讀寫分離」的機制 (有些 Framework ORM 會內建)，自行再程式邏輯將 SELECT Query 分散到 Slave 執行，除非有使用商業的 Proxy Connection Pool 機制，才有提供自動讀寫分離的機制。如果是使用 MariaDB 的話也可以搭配 MaxScale 實現讀寫分離機制，但 MaxScale 我沒玩過，只是打打嘴砲。
此外，建構 Replication 還有一個很重要的好處，就是可以順便備份！一般的情況我們都是用 mysqldump 進行資料備份對吧！？但是如果你的資料已經大到一定的程度，想要 Dump DB 絕對是 GG，搞不好跑個日備份就超過一天了....... 這時候就要借助 Replication 的能力。
透過 HAProxy 實現 MySQL 主備自動切換
上述說明的主從架構只能分散運算，並無法實現 HA 能力，如果採用 Master/Master 的配置方式就可以實現了，但是應用程式要如何判斷其他一台機器出問題呢？我們可以藉由 HAProxy 這個套件來實現。將其中一台機器上線，另一台基器備援 (Replication)，當第一台機器發生問題時，自動由 HAProxy 轉接連線至備援機，以實現 HA 模式。HAProxy 的設定方式在 GitHub 上：https://github.com/samejack/blog-content/blob/master/mysql-replication/haproxy.cfg
