MYSQL的發展背景和特性;
MYSQL的體系架構組成;
MYSQL的各種存儲引擎及適用場景;
MYSQL主從復制的基本原理;
MYSQL常見的主從復制架構和高可用架構;
總結處理復制延遲和復制不一致的問題。
版本介紹:
Mysql GA(ORACLE)
Percon mysql
MariaDB
開源
開放源代碼且無版權制約,自主性強、使用成本低可根據
歷史悠久、社區及用戶非常活躍,遇到問題,可以很快獲取到幫助。
可移植:
支持多種操作系統,提供多種api幾口,支持多種開發語言。
安全:
有著非常完善的用戶和權限系統,當你建立連接時,可以通過加密的方式來保證他通信安全。
Mysql的體系架構:
常用的存儲引擎和特性對比
MYSQL從5.5.5版本開始默認存儲引擎為InnoDB(表級別)
基本概念
MYSQL從3.2.3版本開始提供復制的功能,復制是指將主庫的DDL和DML(除select)操作通過二進制日志傳到服務器上(從庫),然后再從庫上對這些日志重新執行(也叫重做),從而使得從庫和主庫的數據保持同步。
為什么要做主從復制:
z
輔助備份
分擔負載
應用場景
應用場景1:從服務器作為主服務器的實時數據備份
應用場景2:主從服務器實現讀寫分離,服務器實現負載均衡
應用場景3:把多個從服務器根據業務重要性進行拆分訪問
復制的原理
Master:binlog dump 線程。Slave: I/O線程,Slave: SQL線程
異步復制
主節點只需要把寫入操作在本地完成,就響應用戶。
半同步復制&增強半同步復制
為了保證主庫上的每一個binlog事務都能夠被可靠的復制到從庫上,主庫在每次事務提交成功時,并不是及時反饋給客戶端用戶,而是等待其中一個從庫也接收到了binlog并成功將事務記錄到了中繼日志中,然后才反饋給用戶。
rpl_semi_sync_master_timeout
set globalrpl_semi_sync_master_wait_point=AFTER_COMMIT;
半同步復制的配置:
半同步參數需要先注釋掉,等初始化完成之后安裝好半同步插件,再開啟半同步參數
如果是雙主架構則主備庫都需要安裝:
rpl_semi_sync_master_enabled= 1
rpl_semi_sync_slave_enabled= 1
maser
slave
結果:
完全同步的復制
當主庫提交事務之后,所有的從庫節點必須收到、APPLY并且提交這些事務,然后主庫線程才能繼續做后續操作。因為需要等待所有從庫執行完該事務才能返回,所以全同步復制的性能必然會收到嚴重的影響。
一主一從
主主復制
一主多從---擴展系統讀取的性能,因為讀是在從庫讀取的;
多主一從---5.7開始支持
聯級復制
MYSQL的主從復制-高可用架構對比
分類 | MM | MHA | MGR |
優勢 | 主主模式能將讀寫請求分攤到兩個主節點,有效提升服務器使用率。 | MHA除了支持日志點的復制還支持GTID的方式 | 基本無延遲,延遲比異步的小很多 |
主節點發生故障后,能快速進行主從切換。 | 同MMM相比,MHA會嘗試從舊的Master中恢復舊的二進制日志,只是未必每次都能成功。如果希望更少的數據丟失場景,建議使用MHA架構。 | 支持多寫模式,但是目前還不是很成熟 | |
當故障節點恢復后,故障節點能通過復制進行數據恢復(應用其他節點數據)和數據同步(將未同步數據發生給其他節點)。 | 數據的強一致性,可以保證數據事務不丟失 | ||
不足 | 當主節點上MySQL實例發生故障后,可能會存在部分數據(Binlog)未同步到另外的主節點,導致數據丟失(直到故障節點恢復)。 | MHA需要自行開發VIP轉移腳本。 | 僅支持innodb |
主主模式下,很容易因數據訪問控制不當導致數據沖突。 | MHA只監控Master的狀態,未監控Slave的狀態 | 只能用在GTID模式下,且日志格式為row格式 | |
為提高系統高可用性,雙主架構會被擴展成雙主多從結構,同樣存在主節點發生故障后多個從庫選主和恢復復制的問題。 | |||
適用場景 | 讀寫都需要高可用的場景 | 一主多從的環境下,MySQL的主從復制是異步或是半同步。 | 對主從延遲比較敏感 |
希望對對寫服務提供高可用,又不想安裝第三方軟件 | |||
數據強一致的場景 |
如何處理同步延遲
1. 如果是機械盤:
set globalinnodb_flush_neighbors=2;
表示刷新在buffer pool 中位于磁盤上相同的extend 區的臟頁,通過AIO可以將多個IO寫入操作合并為一個IO操作,增大寫入量,減少了物理寫IO。
2.如果是IO的問題:
set globalinnodb_io_capacity=1200; (默認200)
即每秒的輸入輸出量(或讀寫次數)。
3.臨時調整:
set globalinnodb_flush_log_at_trx_commit=2; (默認為1)
set globalsync_binlog=0;
同步之后需要調整回:
set globalinnodb_flush_log_at_trx_commit=1;
set globalsync_binlog=1;
錯誤信息
錯誤分析
mysqlbinlogmysql-bin.xxx -vv --base64-output=decode-rows --start-position=a--stop-position=b>/tmp/test.log
錯誤分析結論
200711 8.49 –9:42期間日志中斷,原因是這段時間內,主機重啟了,而二進制這部分日志傳輸到備庫的時候丟失了。
解決方案
主庫:
確定備庫丟失的二進制日志的內容(根據時間或者位點信息)
經過排查確定丟失的日志為mysql-bin000333中的start-position=362945607 到 stop-position=363101485的內容。
備庫:中端將
mysqlbinlog--skip-gtids --start-position=362945607 --stop-position=363101485mysql-bin000333 |mysql -utest -p -h ip
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/130164.html
摘要:肖鵬微博數據庫那些事兒肖鵬,微博研發中心技術經理,主要負責微博數據庫相關的業務保障性能優化架構設計,以及周邊的自動化系統建設。經歷了微博數據庫各個階段的架構改造,包括服務保障及體系建設微博多機房部署微博平臺化改造等項目。 showImg(https://segmentfault.com/img/bV24Gs?w=900&h=385); 對于手握數據庫的開發人員來說,沒有誤刪過庫的人生是...
摘要:編輯器編輯器背景編輯器前段時間遇到一個線上問題,后來排查好久發現是因為主從同步延遲導致的,所以今天寫一篇文章總結一下這個問題希望對你有用。編輯器幾句嘮叨編輯器大家好,我是小飯,一枚后端工程師。背景前段時間遇到一個線上問題,后來排查好久發現是因為主從同步延遲導致的,所以今天寫一篇文章總結一下這個問題希望對你有用。如果覺得還不錯,記得加個關注點個贊哦思維導圖思維導圖常見的主從架構隨著日益增長的訪...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20