這篇文章將為大家詳細講解有關mysql中Oneproxy如何實現讀寫分離，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
基本架構： 寫請求全部定向到主庫，數據通過日志異步復制到副庫，讀請求可根據情況路由到主庫或者副庫，分散讀壓力目前讀的壓力平均分到3臺服務器，性能提升在20-30%左右
中間件連接池會根據 CONNECTION的AUTO COMMIT 狀態來緩沖連接，如果過程中AUTOCOMMIT的值發生變化，則之前緩存的數據庫連接會失效. 導致重新建立連接性能下降. JDBC事務控制恰恰會主動把CONNECTION的 AUTOCOMMIT屬性設為 FALSE （默認為TRUE). 如果禁用事務，數據完整性得不到保證并且會引發其他錯誤. 好在ONEPROXY最新版本已經解決了這個問題 （題外話，好像MYCAT連接池的設計思路也類似，使用時有沒有坑有待驗證）
在高并發下 ONEPROXY 中間件的連接池大小要調整
ONEPROXY 中間件的字符集要設置成UTF8，默認是GBK, 如果沒有設對，那么對象序列化的BLOB存到MYSQL數據庫會損壞導致無法反序列化
在寫主數據庫，讀多個副數據庫的架構下，最常見的問題是數據復制不及時，導致定向到副庫的讀請求沒有讀到數據ONEPROXY 通過事務控制來解決這個問題，如果讀和寫操作都在一個事務里，那么他們都會到被定向到主數據庫所以事務的邊界控制很重要，但是現在應用的代碼非?；靵y，導致控制事務很困難，ONEPROXY提供了一個折衷的方案，可指定對于某個表定向到主庫/副庫，現在對于讀寫都很頻繁的表，購物車，訂單，訂單行，促銷，支付記錄等一律指定路由到主庫錯誤率目前基本控制在零. 曾經也嘗試過用PERCONA的參數 WSREP_CAUSAL_READS 來解決上述問題，但是并沒有效果
關于“mysql中Oneproxy如何實現讀寫分離”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
