文章來源地址http://www.zghlxwxcb.cn/news/detail-710236.html
1.?復(fù)制切換
1.1.?復(fù)制是高可用性的基礎(chǔ)
1.1.1.?總是保留一份持續(xù)更新的副本數(shù)據(jù)，會讓災(zāi)難恢復(fù)更簡單
1.2.?“切換副本”（promoting a replica）和“故障切換”（failing over）是同義詞
1.2.1.?意味著源服務(wù)器不再接收寫入，并將副本提升為新的源服務(wù)器
1.3.?計劃內(nèi)切換
1.3.1.?常見原因
1.3.1.1.?安全補丁
1.3.1.2.?內(nèi)核更新
1.3.1.3.?一些配置選項更改后需要重新啟動才能生效
1.3.2.?步驟
1.3.2.1.?確定將哪個副本切換為新的源
1.3.2.1.1.?一個包含所有數(shù)據(jù)的副本
1.3.2.2.?檢查延時，確保延時在秒級別
1.3.2.3.?通過設(shè)置super_read_only停止數(shù)據(jù)寫入源服務(wù)器
1.3.2.4.?等待副本與目標(biāo)完全同步
1.3.2.4.1.?通過比較GTID來確定
1.3.2.5.?在目標(biāo)（需要切換為源的副本）上取消read_only設(shè)置
1.3.2.6.?將應(yīng)用流量切換到目標(biāo)上
1.3.2.7.?將所有副本重新指向新的源，包括剛剛被降級為副本的服務(wù)器
1.3.2.7.1.?配置了GTID和AUTO_POSITION=1
1.4.?計劃外切換
1.4.1.?只要時間夠長，每個系統(tǒng)都會因軟件或硬件而出現(xiàn)故障
1.4.2.?當(dāng)故障發(fā)生在承擔(dān)寫入的源服務(wù)器上時，會對用戶體驗產(chǎn)生重大影響
1.4.3.?這時候不再存在一個實時運行的源服務(wù)器了
1.4.4.?步驟
1.4.4.1.?確定需要切換的副本
1.4.4.1.1.?擇數(shù)據(jù)最完整的副本
1.4.4.2.?在目標(biāo)上關(guān)閉read_only設(shè)置
1.4.4.3.?將應(yīng)用流量切換到目標(biāo)上
1.4.4.4.?將所有副本重新指向新源（目標(biāo)服務(wù)器），包括恢復(fù)后的原來提供服務(wù)的源服務(wù)器
1.4.4.4.1.?切換前的源服務(wù)器再次啟動時，需要默認(rèn)啟用super_read_only
1.4.4.4.1.1.?防止任何意外的寫入
1.5.?切換時的權(quán)衡
1.5.1.?很難知道切換后的目標(biāo)（新的源服務(wù)器）可能丟失了多少數(shù)據(jù)
1.5.2.?有時不進行故障切換可能是更好的策略
1.5.3.?等待恢復(fù)的好處不會丟失任何數(shù)據(jù)，并且所有副本將繼續(xù)從中斷的地方工作
2.?復(fù)制拓?fù)?/h2>
2.1.?幾乎任何一個源和副本都可以配置MySQL復(fù)制
2.2.?主動/被動模式
2.2.1.?應(yīng)用將所有讀取和寫入都指向單個源服務(wù)器
2.2.2.?不用擔(dān)心復(fù)制延遲的問題
2.2.3.?可以防止應(yīng)用程序不接受讀取延遲數(shù)據(jù)的問題
2.2.4.?配置
2.2.4.1.?應(yīng)該盡量讓源和副本在CPU、內(nèi)存等方面具有相同的配置
2.2.4.2.?副本上使用相同的硬件和軟件配置就可以確保能夠支持切換之前的應(yīng)用流量容量和吞吐量
2.2.5.?冗余
2.2.5.1.?在物理硬件環(huán)境中，推薦使用至少三臺服務(wù)器的n+2冗余
2.2.5.2.?如果數(shù)據(jù)足夠少，或者可以輕松復(fù)制數(shù)據(jù)，也可以使用至少兩臺服務(wù)器的n+1冗余，否則還是建議n+2
2.2.5.3.?如果無法在源服務(wù)器上進行備份操作，可以使用其中一個副本作為備份服務(wù)器
2.2.6.?注意事項
2.2.6.1.?實際上是將讀擴展綁定到單臺服務(wù)器的容量上
2.2.6.2.?如果達到讀擴展上限
2.2.6.2.1.?則必須演進到更復(fù)雜的拓?fù)?/h5>
2.2.6.2.1.1.?主動/只讀池配置
2.2.6.2.2.?否則就不得不利用分片來減少源上的讀取壓力
2.3.?主動/只讀池配置
2.3.1.?將所有寫入指向源服務(wù)器
2.3.2.?根據(jù)應(yīng)用程序的需要，讀取則可以被發(fā)送到源服務(wù)器或只讀池
2.3.3.?只讀池可以實現(xiàn)讀取密集型應(yīng)用程序的讀水平擴展
2.3.4.?由于源上的復(fù)制請求，水平擴展能力會受到限制
2.3.5.?配置
2.3.5.1.?如果隨著時間的推移，只讀池在持續(xù)增長，則可以讓副本用不同的硬件配置來優(yōu)化成本
2.3.5.2.?將流量進行加權(quán)，運行在更好的硬件配置的副本上可以承擔(dān)更多的流量
2.3.6.?冗余
2.3.6.1.?應(yīng)滿足先前提出的要求，還需要至少一臺服務(wù)器可以充當(dāng)故障切換的目標(biāo)
2.3.7.?注意事項
2.3.7.1.?只讀池的大小會決定管理的復(fù)雜度，以及何時應(yīng)該考慮自動化
2.4.?不推薦的拓?fù)浼軜?gòu)
2.4.1.?雙源主動-主動架構(gòu)
2.4.1.1.?雙向復(fù)制
2.4.1.2.?涉及兩臺服務(wù)器，每臺服務(wù)器都配置為源和另一臺的副本
2.4.1.3.?一對協(xié)同源
2.4.2.?雙源主動-被動模式
2.4.2.1.?主動-主動模式下的雙源服務(wù)器有一個變種
2.4.2.2.?其中一臺服務(wù)器是只讀的“被動”服務(wù)器
2.4.3.?帶有副本的雙源模式
2.4.3.1.?兩個可寫的源只會帶來麻煩
2.4.4.?環(huán)形復(fù)制
2.4.4.1.?具有三個或更多個源，其中每臺服務(wù)器都在環(huán)中，它之前的服務(wù)器是它的副本，它之后的服務(wù)器作為它的源
2.4.4.2.?循環(huán)復(fù)制
2.4.5.?多源復(fù)制
3.?復(fù)制管理和維護
3.1.?在數(shù)據(jù)量很小而且寫入負(fù)載一致的時候，通常不太需要經(jīng)常查看復(fù)制延遲或者復(fù)制中斷相關(guān)的問題
3.2.?復(fù)制監(jiān)控
3.2.1.?復(fù)制同時需要源和副本上的磁盤空間
3.2.2.?監(jiān)控復(fù)制的狀態(tài)和錯誤
3.2.2.1.?如果復(fù)制線程沒有正常運行，那么可以查看報錯信息，以確定下一步應(yīng)該做什么來修復(fù)錯誤
3.2.3.?延遲復(fù)制的實際延遲
3.2.3.1.?太長的延遲可能會使其使用起來更加耗時
3.3.?觀測復(fù)制延遲
3.3.1.?副本與源之間的復(fù)制延遲是多少
3.3.2.?最好的解決方案是心跳記錄，它需要在源上每秒更新一次時間戳
3.3.2.1.?創(chuàng)建了一個方便的時間戳，展示副本中的數(shù)據(jù)在什么時間點是最新的
3.3.2.2.?Percona Toolkit中包含的pt-heartbeat腳本是當(dāng)前最流行的復(fù)制心跳實現(xiàn)方案
3.3.2.3.?二進制日志中的復(fù)制心跳記錄可用于許多目的
3.4.?確定副本數(shù)據(jù)的一致性
3.4.1.?副本始終是其源的精確復(fù)制減去其復(fù)制延遲的部分
3.4.2.?副本與源不一致的原因
3.4.2.1.?意外寫入副本
3.4.2.2.?使用雙源復(fù)制，雙方都寫入了數(shù)據(jù)
3.4.2.3.?非確定性語句和基于語句的復(fù)制
3.4.2.4.?當(dāng)運行在弱持久化模式時MySQL崩潰
3.4.2.5.?MySQL中的Bug
3.4.3.?建議遵循的規(guī)則或配置
3.4.3.1.?在副本上，始終啟用super_read_only
3.4.3.1.1.?使用read_only可以防止沒有SUPER權(quán)限的用戶寫入，但這不會阻止DBA在沒有意識到他們在副本上的情況下運行DELETE或ALTER
3.4.3.1.2.?super_read_only設(shè)置只允許復(fù)制寫入，是運行副本的最安全方式
3.4.3.2.?使用基于行的復(fù)制或確定性語句
3.4.3.2.1.?基于行的復(fù)制是復(fù)制數(shù)據(jù)的最一致的方式
3.4.3.2.2.?使用ORDER BY，使行順序具有確定性
3.4.3.3.?不要嘗試同時寫入復(fù)制拓?fù)渲械亩嗯_服務(wù)器
3.4.3.3.1.?最實用的復(fù)制拓?fù)涫鞘褂靡粋€源，執(zhí)行所有寫入操作，以及一個或多個副本，可選擇地執(zhí)行讀取操作
4.?復(fù)制問題和解決方案
4.1.?使用副本擴展讀取操作，使用分片技術(shù)擴展寫入操作
4.2.?源端二進制日志損壞
4.2.1.?如果源上的二進制日志已被損壞，那么別無選擇，只能重建副本
4.3.?非唯一的服務(wù)器ID
4.3.1.?如果你不小心配置了具有相同服務(wù)器ID的兩個副本，不仔細(xì)觀察的話，它們似乎可以正常工作
4.3.2.?在源服務(wù)器上，任何時候都只能看到兩個副本中的一個
4.3.3.?解決此問題的唯一方法是在設(shè)置副本時要小心
4.3.3.1.?創(chuàng)建副本到服務(wù)器ID映射的規(guī)范列表很有幫助
4.3.3.2.?如果副本完全位于一個子網(wǎng)中，則可以使用每臺機器IP地址的最后一個八位字節(jié)來作為唯一ID
4.4.?未配置服務(wù)器ID
4.4.1.?MySQL將顯示為使用CHANGEREPLICATION SOURCE TO配置了復(fù)制，但不會允許啟動副本
4.4.2.?你可能會從SELECT＠＠server_id中獲得一個值，但這只是一個默認(rèn)值
4.4.2.1.?必須顯式設(shè)置該值
4.5.?臨時表丟失
4.5.1.?臨時表在某些場景中使用起來很方便，但不幸的是，它們與基于語句的復(fù)制不兼容
4.5.2.?如果副本崩潰或?qū)⑵潢P(guān)閉，則副本線程正在使用的任何臨時表都會消失
4.5.3.?當(dāng)重新啟動副本時，引用丟失的臨時表的任何相關(guān)語句都將失敗
4.5.4.?最好的方法是使用基于行的復(fù)制
4.5.4.1.?其次是統(tǒng)一命名臨時表（例如，以temporary_為前綴），然后使用復(fù)制規(guī)則完全跳過復(fù)制臨時表
4.6.?沒有復(fù)制所有變更
4.6.1.?如果誤用SET SQL_LOG_BIN=0或不了解復(fù)制過濾規(guī)則，可能會導(dǎo)致副本不會執(zhí)行源上發(fā)生的某些變更
4.7.?復(fù)制延遲過大
4.7.1.?多線程復(fù)制
4.7.2.?使用分片技術(shù)
4.7.2.1.?使用分片技術(shù)將寫入分散到多個源也是一種非常有效的策略
4.7.3.?臨時降低持久化要求
4.7.3.1.?如果復(fù)制延遲主要是由于寫入操作導(dǎo)致的，則可以臨時設(shè)置sync_binlog=0和innodb_flush_log_at_trx_commit=0以提高復(fù)制速度
4.7.3.2.?最好只在副本上執(zhí)行此操作，如果此副本也用于執(zhí)行備份操作，則更改這些設(shè)置可能會使你無法從備份中恢復(fù)完整的數(shù)據(jù)
4.7.3.3.?一種可能的策略是監(jiān)控SHOW REPLICA STATUS命令中的Seconds_behind_source值，當(dāng)它超過某個閾值時
4.7.3.3.1.?驗證是否啟用了super_read_only，以確保服務(wù)器是不可寫副本
4.7.3.3.2.?更改sync_binlog和innodb_flush_log_at_trx_commit的配置以減少寫操作
4.7.3.3.3.?定期檢查SHOW REPLICA STATUS以獲取Seconds_behind_source的值
4.7.3.3.4.?當(dāng)延遲低于可接受的閾值時，將持久性相關(guān)參數(shù)恢復(fù)到正常值
4.8.?來自源服務(wù)器的超大數(shù)據(jù)包
4.8.1.?當(dāng)源服務(wù)器的max_allowed_packet大小與副本不匹配時，可能會出現(xiàn)另一個難以跟蹤的復(fù)制問題
4.8.2.?源服務(wù)器可以記錄副本認(rèn)為過大的數(shù)據(jù)包，當(dāng)副本檢索該二進制日志事件時，它可能會遇到各種問題，其中包括無休止的錯誤循環(huán)、重試或中繼日志中的損壞
4.9.?磁盤空間耗盡
4.9.1.?當(dāng)源服務(wù)器執(zhí)行大量LOAD DATA INFILE語句并在副本上啟用log_replica_updates時
4.9.2.?復(fù)制延遲越大，用于已從源端獲取但尚未執(zhí)行的中繼日志占用的磁盤空間就越多
4.9.3.?可以通過監(jiān)控磁盤使用情況并設(shè)置relay_log_space參數(shù)來防止這些錯誤出現(xiàn)
4.10.?復(fù)制的限制
4.10.1.?因為MySQL自身固有的一些限制，無論有沒有出現(xiàn)明確的報錯，MySQL復(fù)制都可能失敗或不同步
4.10.2.?服務(wù)器中的bug
4.10.2.1.?MySQL服務(wù)器的許多大版本歷史上都有復(fù)制方面的bug
4.10.2.1.1.?尤其是在大版本的第一個版本中
2.2.6.2.1.1.?主動/只讀池配置
2.2.6.2.2.?否則就不得不利用分片來減少源上的讀取壓力
2.3.?主動/只讀池配置
2.3.1.?將所有寫入指向源服務(wù)器
2.3.2.?根據(jù)應(yīng)用程序的需要，讀取則可以被發(fā)送到源服務(wù)器或只讀池
2.3.3.?只讀池可以實現(xiàn)讀取密集型應(yīng)用程序的讀水平擴展
2.3.4.?由于源上的復(fù)制請求，水平擴展能力會受到限制
2.3.5.?配置
2.3.5.1.?如果隨著時間的推移，只讀池在持續(xù)增長，則可以讓副本用不同的硬件配置來優(yōu)化成本
2.3.5.2.?將流量進行加權(quán)，運行在更好的硬件配置的副本上可以承擔(dān)更多的流量
2.3.6.?冗余
2.3.6.1.?應(yīng)滿足先前提出的要求，還需要至少一臺服務(wù)器可以充當(dāng)故障切換的目標(biāo)
2.3.7.?注意事項
2.3.7.1.?只讀池的大小會決定管理的復(fù)雜度，以及何時應(yīng)該考慮自動化
2.4.?不推薦的拓?fù)浼軜?gòu)
2.4.1.?雙源主動-主動架構(gòu)
2.4.1.1.?雙向復(fù)制
2.4.1.2.?涉及兩臺服務(wù)器，每臺服務(wù)器都配置為源和另一臺的副本
2.4.1.3.?一對協(xié)同源
2.4.2.?雙源主動-被動模式
2.4.2.1.?主動-主動模式下的雙源服務(wù)器有一個變種
2.4.2.2.?其中一臺服務(wù)器是只讀的“被動”服務(wù)器
2.4.3.?帶有副本的雙源模式
2.4.3.1.?兩個可寫的源只會帶來麻煩
2.4.4.?環(huán)形復(fù)制
2.4.4.1.?具有三個或更多個源，其中每臺服務(wù)器都在環(huán)中，它之前的服務(wù)器是它的副本，它之后的服務(wù)器作為它的源
2.4.4.2.?循環(huán)復(fù)制
2.4.5.?多源復(fù)制
3.?復(fù)制管理和維護
3.1.?在數(shù)據(jù)量很小而且寫入負(fù)載一致的時候，通常不太需要經(jīng)常查看復(fù)制延遲或者復(fù)制中斷相關(guān)的問題
3.2.?復(fù)制監(jiān)控
3.2.1.?復(fù)制同時需要源和副本上的磁盤空間
3.2.2.?監(jiān)控復(fù)制的狀態(tài)和錯誤
3.2.2.1.?如果復(fù)制線程沒有正常運行，那么可以查看報錯信息，以確定下一步應(yīng)該做什么來修復(fù)錯誤
3.2.3.?延遲復(fù)制的實際延遲
3.2.3.1.?太長的延遲可能會使其使用起來更加耗時
3.3.?觀測復(fù)制延遲
3.3.1.?副本與源之間的復(fù)制延遲是多少
3.3.2.?最好的解決方案是心跳記錄，它需要在源上每秒更新一次時間戳
3.3.2.1.?創(chuàng)建了一個方便的時間戳，展示副本中的數(shù)據(jù)在什么時間點是最新的
3.3.2.2.?Percona Toolkit中包含的pt-heartbeat腳本是當(dāng)前最流行的復(fù)制心跳實現(xiàn)方案
3.3.2.3.?二進制日志中的復(fù)制心跳記錄可用于許多目的
3.4.?確定副本數(shù)據(jù)的一致性
3.4.1.?副本始終是其源的精確復(fù)制減去其復(fù)制延遲的部分
3.4.2.?副本與源不一致的原因
3.4.2.1.?意外寫入副本
3.4.2.2.?使用雙源復(fù)制，雙方都寫入了數(shù)據(jù)
3.4.2.3.?非確定性語句和基于語句的復(fù)制
3.4.2.4.?當(dāng)運行在弱持久化模式時MySQL崩潰
3.4.2.5.?MySQL中的Bug
3.4.3.?建議遵循的規(guī)則或配置
3.4.3.1.?在副本上，始終啟用super_read_only
3.4.3.1.1.?使用read_only可以防止沒有SUPER權(quán)限的用戶寫入，但這不會阻止DBA在沒有意識到他們在副本上的情況下運行DELETE或ALTER
3.4.3.1.2.?super_read_only設(shè)置只允許復(fù)制寫入，是運行副本的最安全方式
3.4.3.2.?使用基于行的復(fù)制或確定性語句
3.4.3.2.1.?基于行的復(fù)制是復(fù)制數(shù)據(jù)的最一致的方式
3.4.3.2.2.?使用ORDER BY，使行順序具有確定性
3.4.3.3.?不要嘗試同時寫入復(fù)制拓?fù)渲械亩嗯_服務(wù)器
3.4.3.3.1.?最實用的復(fù)制拓?fù)涫鞘褂靡粋€源，執(zhí)行所有寫入操作，以及一個或多個副本，可選擇地執(zhí)行讀取操作
4.?復(fù)制問題和解決方案
4.1.?使用副本擴展讀取操作，使用分片技術(shù)擴展寫入操作
4.2.?源端二進制日志損壞
4.2.1.?如果源上的二進制日志已被損壞，那么別無選擇，只能重建副本
4.3.?非唯一的服務(wù)器ID
4.3.1.?如果你不小心配置了具有相同服務(wù)器ID的兩個副本，不仔細(xì)觀察的話，它們似乎可以正常工作
4.3.2.?在源服務(wù)器上，任何時候都只能看到兩個副本中的一個
4.3.3.?解決此問題的唯一方法是在設(shè)置副本時要小心
4.3.3.1.?創(chuàng)建副本到服務(wù)器ID映射的規(guī)范列表很有幫助
4.3.3.2.?如果副本完全位于一個子網(wǎng)中，則可以使用每臺機器IP地址的最后一個八位字節(jié)來作為唯一ID
4.4.?未配置服務(wù)器ID
4.4.1.?MySQL將顯示為使用CHANGEREPLICATION SOURCE TO配置了復(fù)制，但不會允許啟動副本
4.4.2.?你可能會從SELECT＠＠server_id中獲得一個值，但這只是一個默認(rèn)值
4.4.2.1.?必須顯式設(shè)置該值
4.5.?臨時表丟失
4.5.1.?臨時表在某些場景中使用起來很方便，但不幸的是，它們與基于語句的復(fù)制不兼容
4.5.2.?如果副本崩潰或?qū)⑵潢P(guān)閉，則副本線程正在使用的任何臨時表都會消失
4.5.3.?當(dāng)重新啟動副本時，引用丟失的臨時表的任何相關(guān)語句都將失敗
4.5.4.?最好的方法是使用基于行的復(fù)制
4.5.4.1.?其次是統(tǒng)一命名臨時表（例如，以temporary_為前綴），然后使用復(fù)制規(guī)則完全跳過復(fù)制臨時表
4.6.?沒有復(fù)制所有變更
4.6.1.?如果誤用SET SQL_LOG_BIN=0或不了解復(fù)制過濾規(guī)則，可能會導(dǎo)致副本不會執(zhí)行源上發(fā)生的某些變更
4.7.?復(fù)制延遲過大
4.7.1.?多線程復(fù)制
4.7.2.?使用分片技術(shù)
4.7.2.1.?使用分片技術(shù)將寫入分散到多個源也是一種非常有效的策略
4.7.3.?臨時降低持久化要求
4.7.3.1.?如果復(fù)制延遲主要是由于寫入操作導(dǎo)致的，則可以臨時設(shè)置sync_binlog=0和innodb_flush_log_at_trx_commit=0以提高復(fù)制速度
4.7.3.2.?最好只在副本上執(zhí)行此操作，如果此副本也用于執(zhí)行備份操作，則更改這些設(shè)置可能會使你無法從備份中恢復(fù)完整的數(shù)據(jù)
4.7.3.3.?一種可能的策略是監(jiān)控SHOW REPLICA STATUS命令中的Seconds_behind_source值，當(dāng)它超過某個閾值時
4.7.3.3.1.?驗證是否啟用了super_read_only，以確保服務(wù)器是不可寫副本
4.7.3.3.2.?更改sync_binlog和innodb_flush_log_at_trx_commit的配置以減少寫操作
4.7.3.3.3.?定期檢查SHOW REPLICA STATUS以獲取Seconds_behind_source的值
4.7.3.3.4.?當(dāng)延遲低于可接受的閾值時，將持久性相關(guān)參數(shù)恢復(fù)到正常值
4.8.?來自源服務(wù)器的超大數(shù)據(jù)包
4.8.1.?當(dāng)源服務(wù)器的max_allowed_packet大小與副本不匹配時，可能會出現(xiàn)另一個難以跟蹤的復(fù)制問題
4.8.2.?源服務(wù)器可以記錄副本認(rèn)為過大的數(shù)據(jù)包，當(dāng)副本檢索該二進制日志事件時，它可能會遇到各種問題，其中包括無休止的錯誤循環(huán)、重試或中繼日志中的損壞
4.9.?磁盤空間耗盡
4.9.1.?當(dāng)源服務(wù)器執(zhí)行大量LOAD DATA INFILE語句并在副本上啟用log_replica_updates時
4.9.2.?復(fù)制延遲越大，用于已從源端獲取但尚未執(zhí)行的中繼日志占用的磁盤空間就越多
4.9.3.?可以通過監(jiān)控磁盤使用情況并設(shè)置relay_log_space參數(shù)來防止這些錯誤出現(xiàn)
4.10.?復(fù)制的限制
4.10.1.?因為MySQL自身固有的一些限制，無論有沒有出現(xiàn)明確的報錯，MySQL復(fù)制都可能失敗或不同步
4.10.2.?服務(wù)器中的bug
4.10.2.1.?MySQL服務(wù)器的許多大版本歷史上都有復(fù)制方面的bug
4.10.2.1.1.?尤其是在大版本的第一個版本中
文章來源：http://www.zghlxwxcb.cn/news/detail-710236.html
到了這里，關(guān)于讀高性能MySQL（第4版）筆記17_復(fù)制（下）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
