一、複製的工作原理
- 複製(replication)是MySQL數據庫提供的一種高可用高性能的解決方案，一般用來建立大型的應用
- 總體來說，replication的工作原理分爲以下3個步驟：
- 主服務器（master）把數據更改記錄到二進制日誌（binlog）中
- 從服務器（save）把主服務器的二進制日誌複製到自己的中繼日誌（relay log）中
- 從服務器重做中繼日誌中的日誌，把更改應用到自己的數據庫上，以達到數據的最終一致性
- 複製的工作原理並不複雜，其實就是一個完全備份加上二進制日誌備份的還原。不同的是這個二進制日誌的還原操作基本上實時在進行中
- 這裏特別需要注意的是，複製不是完全實時地進行同步，而是異步實時。這中間存在主從服務器之間的執行延時，如果主服務器的壓力很大，則可能導致主從服務器延時較大
複製的工作原理如下圖所示：
- 從服務器有2個線程：
- 一個是IO線程，負責讀取主服務器的二進制日誌，並將其保存爲中繼日誌
- 另一個是SQL線程，複製執行中繼日誌
- MySQL4.0版本之前，從服務器只有1個線程，既負責讀取二進制日誌，又負責執行二進制日誌中的SQL語句。這種方式不符合高性能的要求，目前已淘汰
二、相關命令
- 因此如果查看一個從服務器的狀態，應該可以看到類似如下內容：
- 可以看到ID爲1的線程就是IO線程，目前的狀態是等待主服務器發送二進制日誌
- ID爲2的線程是SQL線程，負責讀取中繼日誌並執行。目前的狀態是已讀取所有的中繼日誌，等待中繼日誌被IO線程更新
SHOW FULL PROCESSLIST\G
- 在replication的主服務器上應該可以看到一個線程負責發送二進制日誌，類似內容如下：
SHOW FULL PROCESSLIST\G
- 之前已經說過 MySQL的複製是異步實時的，並非完全的主從同步。若用戶要想得知當前的延遲，可以通過下面命令得知，如：
SHOW SLAVE STATUS;
SHOW MASTER STATUS;
- 通過SHOW SLAVE STATUS命令可以觀察當前複製的運行狀態，一些主要的變量如下表所示：
- 命令SHOW MASTER STATUS可以用來查看主服務器中二進制日誌的狀態，如：
- 可以看到,當前二進制日誌記錄了偏移量606181078的位置，該值減去這一時間點時從服務器上的Read_Master_Log_Pos，就可以得知IO線程的延時
- 對於一個優秀的 MySQL數據庫複製的監控，用戶不應該僅僅監控從服務器上IO線程和SQL線程運行得是否正常，同時也應該監控從服務器和主服務器之間的延遲，確保從服務器上的數據庫總是儘可能地接近於主服務器上數據庫的狀態
三、快照+複製的備份架構
- 複製可以用來作爲備份，但功能不僅限於備份，其主要功能如下：
- 數據分佈。由於 MySQL數據庫提供的複製並不需要很大的帶寬要求，因此可以在不同的數據中心之間實現數據的複製
- 讀取的負載平衡。通過建立多個從服務器，可將讀取平均地分佈到這些從服務器中，並且減少了主服務器的壓力。一般通過DNS的 Round-Robin和 Linux的LVS功能都可以實現負載平衡
- 數據庫備份。複製對備份很有幫助，但是從服務器不是備份，不能完全代替備份
- 高可用性和故障轉移。通過複製建立的從服務器有助於故障轉移，減少故障的停機時間和恢復時間
- 可見，複製的設計不是簡簡單單用來備份的，並且只是用複製來進行備份是遠遠不夠的。假設當前應用採用了主從的複製架構，從服務器作爲備份。這時，一個初級DBA執行了誤操作，如 DROP DATABASE或 DROP TABLE，這時從服務器也跟着運行了。這時用戶怎樣從服務器進行恢復呢？
- 因此，一個比較好的方法是通過對從服務器上的數據庫所在分區做快照，以此來避免誤操作對復製造成影響。當發生主服務器上的誤操作時，只需要將從服務器上的快照進行恢復，然後再根據二進制日誌進行point-in-time的恢復即可
- 因此快照+複製的備份架構如下圖所示：
- 還有一些其他的方法來調整複製，比如採用延時複製，即間歇性地開啓從服務器上的同步，保證大約一小時的延時。這的確也是一個方法，只是數據庫在高峯和非高峯期間每小時產生的二進制日誌量是不同的，用戶很難精準地控制。另外，這種方法也不能完全起到對誤操作的防範作用
- 此外，建議在從服務上啓用read-only選項，這樣能保證從服務器上的數據僅與主服務器進行同步，避免其他線程修改數據。如
[mysqld]
read-only
- 在啓用read-only選項後，如果操作從服務器的用戶沒有 SUPER權限，則對從服務器進行任何的修改操作會拋出一個錯誤，如：
