文章來源地址http://www.zghlxwxcb.cn/news/detail-710212.html
1.?概述
1.1.?復制解決的基本問題是讓一臺服務器的數據與其他服務器保持同步
1.2.?在源服務器（source server）上，任何數據修改和數據結構變更的事件（event）都會被寫入日志文件中
1.3.?副本服務器從源服務器上的日志文件中讀取這些事件并在本地重放執(zhí)行
1.4.?一個異步處理的過程
1.4.1.?不能保證副本服務器上的數據是最新的
1.4.2.?復制延遲（副本數據和最新數據之間的時間差）也并沒有上限
1.5.?MySQL復制是其內置的一把“瑞士軍刀”
1.6.?MySQL的復制基本上是向后兼容的
1.6.1.?新版本的服務器可以作為老版本的服務器的副本
1.6.2.?老版本的服務器作為新版本的服務器的副本通常是不可行的
1.7.?通過復制可以將讀操作指向副本來獲得更好的讀擴展性
1.7.1.?并不適合通過復制來擴展寫操作
1.8.?在一主庫多副本庫的架構中，寫操作會被執(zhí)行多次，這時候整個系統(tǒng)的性能取決于寫入最慢的那部分
1.9.?在復制架構中，讀取和重放日志事件是解耦的
1.9.1.?允許讀取日志和重放日志異步進行
1.9.2.?I/O線程和SQL線程都是可以獨立運行的
2.?用途
2.1.?數據分發(fā)
2.1.1.?不會對帶寬造成很大的壓力
2.1.2.?基于行的復制會比傳統(tǒng)的基于語句的復制模式的帶寬壓力更大
2.1.3.?如果為了保持很低的復制延遲，最好有一個穩(wěn)定的、低延遲連接
2.2.?讀流量擴展
2.2.1.?可以將讀操作分布到多臺服務器上，實現對讀密集型應用的優(yōu)化
2.2.2.?對于小規(guī)模的應用，可以簡單地對機器名做硬編碼或使用DNS輪詢
2.3.?備份
2.3.1.?一項有助于備份的有價值的技術，但副本不是備份，也不能夠取代備份
2.4.?分析與報告
2.4.1.?為報告/分析（在線分析處理，OLAP）查詢使用專用的副本是一項很好的策略
2.4.2.?可以很好地隔離此類查詢產生的壓力，以避免對滿足外部客戶需求的在線業(yè)務產生影響
2.5.?高可用性和故障切換
2.5.1.?有助于避免MySQL成為應用程序中的單點故障
2.5.2.?一個包含復制的設計良好的故障切換系統(tǒng)能夠顯著地縮短宕機時間
2.6.?MySQL升級測試
2.6.1.?先使用一個更高版本的MySQL作為副本，確保查詢能夠在此副本上按照預期執(zhí)行，再升級所有的實例
3.?步驟
3.1.?源端把數據更改記錄到二進制日志中，稱之為“二進制日志事件”（binary log events）
3.2.?副本將源上的日志復制到自己的中繼日志中
3.3.?副本讀取中繼日志中的事件，將其重放到副本數據之上
4.?原理
4.1.?復制格式
4.1.1.?基于語句的
4.1.1.1.?通過記錄所有在源端執(zhí)行的數據變更語句來實現的
4.1.1.2.?簡單且緊湊
4.1.1.3.?一條更新了大量數據的SQL語句，在二進制日志中可能僅僅需要幾十字節(jié)存儲
4.1.1.4.?“不確定性”的SQL語句問題
4.1.1.4.1.?如果在源和副本上，記錄的排序不同，這條SQL語句在源和副本上刪除的100條記錄就會不同，這將導致數據不一致
4.1.1.5.?除非某些場景下明確需要臨時使用基于語句的復制
4.1.2.?基于行的
4.1.2.1.?每條被改變的記錄都會作為事件被寫入二進制日志
4.1.2.2.?讓二進制日志的大小發(fā)生巨大的增長
4.1.2.3.?建議堅持使用基于行的復制
4.1.2.3.1.?提供了最安全的數據復制方法
4.1.3.?混合模式
4.1.3.1.?the mixed method
4.1.3.2.?事件的寫入，默認使用基于語句的格式，僅在需要時才切換到基于行的格式
4.1.3.3.?在寫入每個事件時會有很多的判斷條件，以確定使用哪種格式，而這也會導致二進制日志中出現不可預測的事件
4.1.3.4.?不使用
4.2.?全局事務標識符
4.2.1.?GTID
4.2.2.?使用GTID，源服務器提交的每個事務都被分配一個唯一標識符
4.2.3.?由server_uuid和一個遞增的事務編號組成的
4.2.4.?當事務被寫入二進制日志時，GTID也隨之被寫入
4.2.4.1.?當SQL線程提交事務時，它也會將GTID標記為執(zhí)行完成
4.2.5.?GTID解決了運行MySQL復制的一個令人痛苦的問題：處理日志文件和位置
4.2.6.?強烈建議在數據庫中啟用GTID
4.3.?崩潰后的復制安全
4.3.1.?innodb_flush_log_at_trx_commit=1
4.3.1.1.?可以保障每個事務日志都被同步地寫到磁盤
4.3.1.2.?這是一個符合ACID要求的配置，將最大限度地保護你的數據
4.3.1.3.?二進制日志事件首先被提交，然后事務將被提交并寫入磁盤
4.3.1.4.?此參數設置為1將增加磁盤寫入操作的頻次，同時確保數據的持久性
4.3.2.?sync_binlog=1
4.3.2.1.?控制MySQL將二進制日志數據同步到磁盤的頻率
4.3.2.2.?設置為1意味著在每次事務執(zhí)行的時候都會把二進制日志同步寫入磁盤
4.3.2.3.?可以防止在服務器崩潰時丟失事務
4.3.2.4.?會增加磁盤寫入量
4.3.3.?relay_log_info_repository=TABLE
4.3.3.1.?信息將被轉移到MySQL本身的InnoDB表中，允許復制更新同一事務中的事務和中繼日志信息
4.3.3.2.?會在一個原子操作中完成，并有助于崩潰恢復
4.3.4.?relay_log_recovery=ON
4.3.4.1.?使得副本服務器在檢測到崩潰時會丟棄所有本地中繼日志，并從源服務器中獲取丟失的數據
4.3.4.2.?確保了在崩潰中發(fā)生的磁盤上的任何損壞或不完整的中繼日志都是可恢復的
4.3.4.3.?不再需要配置sync_relay_log
4.3.4.3.1.?因為在發(fā)生崩潰時，中繼日志將被刪除，也就無須花費額外的操作將它們同步到磁盤
4.4.?延遲復制
4.4.1.?某些副本有一些延遲反而是有好處的
4.4.2.?可以讓副本中的數據保持在線并且持續(xù)運行，但同時落后于源數據庫數小時或者數天
4.4.3.?配置語句是CHANGEREPLICATION SOURCE TO，配置選項為SOURCE_DELAY
4.4.4.?場景
4.4.4.1.?刪除了一個表
4.4.4.1.1.?從備份中恢復可能需要幾個小時
4.4.4.1.2.?如果使用了延遲復制的副本，則可以找到DROP TABLE語句對應的GTID，使副本服務器的復制運行到表被刪除之前的時間點，這會大大減少修復時間
4.5.?多線程復制
4.5.1.?在副本端運行多個SQL線程，從而加快本地中繼日志的應用
4.5.2.?兩種模式
4.5.2.1.?DATABASE模式
4.5.2.1.1.?使用多線程更新不同的數據庫
4.5.2.1.2.?但不會有兩個線程同時更新同一個數據庫
4.5.2.1.3.?將數據分布在MySQL的多個數據庫中，則可以同時并且一致地更新它們，這種模式非常有效
4.5.2.2.?LOGICAL_CLOCK模式
4.5.2.2.1.?允許對同一個數據庫進行并行更新，只要它們都是同一個二進制日志組提交的一部分
4.5.2.2.2.?人工延遲的配置參數
4.5.2.2.2.1.?binlog_group_commit_sync_delay（以微秒為單位的延遲）
4.5.2.2.2.2.?binlog_group_commit_sync_no_delay_count（決定中止等待之前要等待的事務數）
4.5.2.2.2.3.?確保你的副本配置了參數replica_preserve_commit_order，這樣就不會出現無序提交的問題
4.6.?半同步復制
4.6.1.?在啟用半同步復制后，源在完成每個事務提交時，都需要確保事務至少被一個副本所接收
4.6.2.?需要確認副本已收到并成功將其寫入自己的中繼日志（但不一定應用到本地數據）
4.6.3.?如果在一定時間范圍內沒有副本確認事務，MySQL將恢復到標準的異步復制模式
4.6.4.?半同步復制不是一種防止數據丟失的方法，而是可以讓你擁有更具彈性的故障切換的更大工具集的一部分
4.6.5.?建議不要依賴該功能來保證數據完整性
4.7.?復制過濾器
4.7.1.?可以讓副本僅復制一部分數據
4.7.2.?復制過濾器是一顆定時炸彈
4.7.3.?從源上的二進制日志中過濾事件
4.7.3.1.?binlog_do_db
4.7.3.2.?binlog_ignore_db
4.7.3.3.?不僅有可能破壞復制，還會使從備份中進行時間點恢復變得不可能
4.7.3.3.1.?在大多數情況下都不應該使用它們
4.7.4.?從副本上的中繼日志中過濾事件
4.7.4.1.?replication_*選項在SQL線程從中繼日志中讀取事件時過濾事件
文章來源：http://www.zghlxwxcb.cn/news/detail-710212.html
到了這里，關于讀高性能MySQL（第4版）筆記16_復制（上）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
