MySQL架構的優化

時間  2019-11-29
標籤 mysql 架構 優化 欄目 MySQL 简体版
原文   原文鏈接

  • mysql的複製：html

    實如今不一樣服務器上的分佈：
  	利用二進制日誌增量進行；
  	不須要太多的帶寬，可是使用基於行的複製在進行大批量的更改時，會對帶寬帶來必定的壓力，特別是跨IDC環境下進行的複製；	
  	應該分批進行
  實現數據讀取的負載均衡，須要其餘組件配合使用
  增長數據的安全性
  實現數據庫高可用和故障切換
  實現數據庫在線升級
複製代碼

  • mysql的二進制日誌：記錄了全部對MySQL數據庫的數據增刪查改和對錶和數據庫的修改前端

  • binlog命令行的工具進行查看node

    二進制日誌格式：mysql

    基於段的日誌格式： binlog_format=STATEMENT

  基於行的日誌格式： binlog_format=ROW
  	binlog_row_image=[FULL|MINIMAL|NOBLOB]

  mysqlbinlog -vv 日誌文件名稱；
  
  混合日誌格式：binlog_format=MIXED
  	根據sql語句由系統決定使用基於段仍是基於行的日誌格式；
  	數據量的大小由所執行的sql語句決定
複製代碼

    建議使用binlog_format=MIXED 或者 binlog_format=ROW並設置binlog_row_image=MINIMALsql

  • 基於SQL語句的複製(SBR)數據庫

    優勢： 生成的日誌量少，節約網絡傳輸IO 並不強制要求主從數據庫的表定義徹底相同 相比於基於行的複製方式更爲靈活安全

    缺點： 對於非肯定性事件，沒法保證主從數據的一致性 對於存儲過程，觸發器，自定義函數進行的修改也能夠形成數據不一致 相對於基於行的複製方式在從上執行時須要更多的行鎖服務器

  • 基於行的複製（PBR）網絡

    優勢：多線程

    能夠應用於任何SQL的複製包括非肯定肯定函數，存儲過程等；
  能夠減小數據庫鎖的使用
複製代碼

    缺點：

    要求主從數據庫的表的結構相同，負責可能會中斷複製；
  沒法在從服務器上單獨執行觸發器
複製代碼

  • mysql複製的工做方式

mysql複製的工做方式

  1. 主服務器將變動寫入到二進制文件中
  2. 從服務器讀取主服務器的二進制日誌變動寫入到relay_log中
  3. 在從服務器上重放rely_log中的日誌
基於日誌點的複製配置的步驟：
1.在主DB服務器上創建複製帳號
	
	create user 'repl' @ 'IP段' identified by 'password';
	grant replication slave on *.* to 'repl' @ 'IP段';//受權
	
2.配置主庫服務器

	bin_log=mysql-bin
	server_id = 100

3.配置數據庫從服務器
	
	bin_log = mysql-bin
	server_id = 101
	relay_log = mysql-relay-bin
	log_slave_update = on[可選]
	read_only = on[可選]

4.初始化從服務器數據
	
	mysqldump --master-data=2 -single-transaction
	xtrabackup --slave-info[對innodb性能不進行鎖表]

5.啓動複製鏈路
	
	change master to master_host = '主服務器的ip地址' ，
		master_user = 'repl'，
		master_password = 'password'，
		master_log_file = 'mysql_log_file_name'，
		master_log_pos = 4; 
實際的配置：

	1.配置主庫：
		create user repl@'192.168.25.%' identified by '123456';
		grant replication slave on *.* to repl@'192.168.25.%';
	
	2.修改主從配置文件

	3.主數據庫備份：mysqldump --single-transcation --master-data --triggers --			routines --all-databases >> all.sql

	4.將主庫的生成的備份文件傳遞到從服務器上：scp all.sql root@192.168.15.130:/root

	5.在從服務器上執行該sql文件： mysql -uroot -p < all.sql

	6.在從服務器上配置數據鏈路：change master to master_host='192.168.25.33',
							master_user='repl',
							master_password='123456',
							master_log_file='mysql-bin.0000003',
							mater_log_pos=1829; 
	
	7.在從服務器上啓動複製鏈路：start slave;
基於日誌點的複製優勢：
	是mysql最先的複製技術，bug較少
	對於sql查詢沒有任何限制
	故障處理比較容易
基於日誌點的複製缺點：
	故障轉移時從新獲取新主的日誌點的信息比較困難
複製代碼
基於GTID的複製配置的步驟：
1.在主DB服務器上簡歷複製帳號
	
		create user 'repl' @ 'IP段' identified by 'password';
		grant replication slave on *.* to 'repl' @ 'IP段';//受權
	
	2.配置主庫服務器

		bin_log=mysql-bin
		server_id = 100
		gtid_mode = on
		
		enforce-gtid-constistency
			不支持如下操做：create table ... select
						  在事務中使用create temporary創建臨時表
						  使用關聯更新事務表和非事務表
		log-slave-updates = on[5.7版本以前加]

	3.配置數據庫從服務器
	
		server_id = 101
		relay_log = mysql-relay-bin
		gtid_mode=on
		enforce-gtid-constistency
		read_only = on[可選]
		master_info_repository=table
		relay_log_info_repository=table
	
	4.初始化從服務器數據
	
		mysqldump --master-data=2 -single-transaction
		xtrabackup --slave-info

	5.啓動複製鏈路
		
		change master to master_host = '主服務器的ip地址' ，
			master_user = 'repl'，
			master_password = 'password'，
			master_auto_position=1;

基於gtid的複製的優勢：
	能夠很方便的進行故障的轉移
	從庫不會丟失主庫上的任何修改

基於gtid的複製的缺點：
	故障處理比較複雜
	對執行的SQL有必定的限制
複製代碼

  • 如何選擇複製模式

    1. 所使用的MySQL版本
    2. 複製的架構及主從切換的方式
    3. 所使用的高可用管理組件
    4. 對應用的支持程度

  • MySQL複製拓撲結構

    MySQL5.7以前，一個從庫只能有一個主庫

    MySQL5.7以後支持一從多主架構

常見的拓撲的設計及設計的注意事項:

  • 一主多從的複製拓撲

一主多從的複製拓撲 

優勢：配置簡單
	 能夠用多個從庫分擔讀負載

用途：爲不一樣業務使用不一樣的從庫
	 將一臺從庫放到遠程的IDC中，用做災備恢復
	 分擔主庫的讀負載
複製代碼
  • 主-主複製拓撲

主-主複製拓撲 

缺點：
	產生數據衝突而形成複製鏈路的中斷
	耗費大量的時間
	形成數據的丟失

主主模式下的主主複製的配置的注意事項：
	兩個主中所操做的表最好可以分開
	使用下面兩個參數自增ID的生成
		auto_increment_increment = 2
		auto_increment_offset = 1|2
複製代碼
  • 主-備複製的拓撲

主-備複製的拓撲 

特色：
	只有一臺主服務器對外提供服務
	一臺服務器處於只讀狀態而且只做爲熱備使用
	在對外提供的主庫出現故障或是計劃性的維護時纔會進行切換,使原來的備庫成爲主庫，而原來的主庫會成爲新的備庫並處理只讀或下線狀態，待維護完成後從新上線

主備模式下的主主複製的配置的注意事項：
	確保兩臺服務器上的初始化的初始數據相同
	確保兩臺服務器上已經啓動binlog而且有不一樣的server_id
	在兩臺服務器上啓用log_slave_updates參數
	在初始的備庫上啓用read_only
複製代碼
  • 帶從服務器的主主複製的拓撲

帶從服務器的主主複製的拓撲

  • 級聯複製的拓撲

    將一個主服務器配置一個從服務器經過從服務器來分發進行復制

    mysql級聯複製

MySQL複製性能的優化

  • 影響主從延遲的因素
  1. 主庫寫入二進制日誌的時間 --> 控制主庫中執行事務的大小，分隔大事務
  2. 二進制日誌傳輸時間 --> 使用mixed日誌格式，設置set binlog_row_image=minimal;
  3. 默認狀況下只有一個SQL線程，主上併發修改在從上變成了串行化 --> 使用多線程複製

  • 如何在MySQL5.7中配置數據庫的多線程的複製[MYSQL5.6中引入多線程的複製,在MySQL5.7中能夠按照邏輯時鐘的方式來分配SQL線程]：

    1.stop slave //中止主從複製 2.set global slave_parallel_type='logical_clock'; //設置分配線程的方式 3.set global slave_parallel_workers=4; //設置4個複製線程 4.start slave;

MySQL複製常見的問題

  • 因爲數據的損壞或者丟失所引發的主從複製錯誤

    主庫或者從庫的意外宕機所引發的錯誤 --> 跳過二進制日誌的事件/注入空事務的方式先恢復中斷的複製鏈路，再使用其餘的方法來對比主從服務器上的數據

    主庫上的二進制日誌損壞 --> 經過change master命令來從新指定

    備庫上的中繼日誌損壞

    在從庫上進行數據修改形成的主從複製的錯誤

    不惟一的server_id或者server_uuid(server_uuid是記錄在數據目錄中的auto.cnf文件中，一旦存在mysql不會生成server_uuid)

    max_allow_packet設置引發的主從複製錯誤

MySQL主從複製沒法解決的問題

  • 沒法分擔主數據庫的寫負載
  • 沒法自動進行故障轉移及主從切換
  • 不提供讀寫分離的功能

利用主從複製搭建高可用的架構

  • 高可用性指的是經過儘可能縮短因平常維護操做（計劃）和突發的系統崩潰（非計劃）所致使的體積世家你，以提升系統和應用的可用性。

  • 實現高可用

    》避免致使系統不可用的因素，減小系統不可用的時間[服務器磁盤空間耗盡、性能低下的SQL、表結構和索引沒有優化、主從數據不一致、人爲的操做失誤]

    》創建完善的監控及報警系統

    》對備份數據進行恢復測試

    》正確配置數據庫環境

    》對不須要的數據進行歸檔和清理

    》增長系統冗餘，保證發生系統不可用時能夠儘快的恢復[避免存在單點故障、主從切換及故障轉移]

    利用sun共享存儲或者drdb磁盤複製解決MySQL單點故障
  利用多寫集羣或者NDB集羣來解決MySQL單點的故障
  利用MySQL的複製來解決MySQL的單點登陸的問題
複製代碼

MySQL數據庫的MMM架構

在主庫出現宕機時進行故障轉移並自動配置其餘從對新主的複製

提供了主，寫虛擬ip，在主從服務器出現問題時能夠自動遷移虛擬ip

MySQL數據庫的MMM架構

  • MMM部署所需資源
名稱資源 數量 說明
主DB服務器 2 用於主備模式的主主複製配置
從DB服務器 0-N 能夠配置0臺或多臺從服務器，但建議不要太多
監控服務器 1 用於監控mysql監控集羣
IP地址 2*(n+1) n爲MySQL服務器的數量
監控用戶 1 用於監控數據庫狀態的MySQL用戶(replication client)
代理用戶 1 用於MMM代理的MySQL用戶(super,replication client,process)
複製用戶 1 用於配置MySQL複製的MySQL用戶(replication slave)
MMM架構的部署步驟

  1. 配置主主複製及主從同步集羣

  2. 安裝主從節點所須要的支持包（per依賴包）

  3. 安裝及配置MMM工具集

  4. 運行MMM監控

  5. 測試

MySQL高可用架構之MMM架構的詳細配置

MMM集羣的優缺點：

》MMM集羣的優勢：

  1. 使用Perl腳本語言開發及徹底開源
  2. 提供了讀寫VIP(虛擬IP),使服務器角色的變動對前端應用透明
  3. MMM提供了從服務器的延遲監控
  4. MMM提供了主數據庫故障轉移後從服務器對新主的從新同步的功能
  5. 很容易對發生故障的主數據庫從新上線
  6. MMM提供了從服務器的延遲監控

》MMM集羣的缺點：

  1. 發佈時間比較早不支持MySQL新的複製功能
  2. 沒有讀負載均衡的功能
  3. 在進行主從切換時，容易形成數據丟失
  4. MMM監控服務存在單點故障

MySQL數據庫的MHA架構

監控主數據庫服務器是否可用

當主DB不可用時，從多個從服務器中選舉出新的主數據庫服務器

提供了主從切換和故障轉移功能（MHA能夠半同步功能結合起來使用）

  • MHA如何進行主從切換

    當主數據庫出現故障時，嘗試從出現故障的主數據庫保存二進制日誌

    從多個備選從服務器中選舉出新的備選主服務器

    在備選主服務器和其它從服務器之間同步差別二進制數據

    應用從原主DB服務器上保存的二進制日誌

    提高備選主DB服務器爲新的主DB服務器

    遷移集羣中的其它從DB作爲新的主DB的從服務器

  • MHA支持GTID的複製和日誌點的複製

  • MMM不支持GTID的複製

MHA架構的部署步驟

  1. 配置集羣內全部服務器的SSH的免認證登陸

    ssh -keygen

    ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.100

    ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.101

    ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.102

  2. 安裝MHA-node軟件包和MHA-manager軟件包

  3. 安裝MHA的支持包

    監控節點：yum -y install perl-Config-Tiny.noarch perl-Time-HiRes.X86_64 perl-Parallel-ForkManager perl-Log-Dispatch-Perl.noarch per-DB-MySQL ncftp

    數據節點：yum -y install perl -DBD-MySQL ncftp perl-DBI.X86

  4. 創建主從複製集羣

  5. 配置MHA管理節點

  6. 使用master_check_ssh和masterha_check_repl對配置進行檢驗

  7. 啓動並測試MHA服務

MySQL高可用架構之MHA介紹及配置

MHA集羣的優缺點：

》MHA集羣的優勢：

  1. 使用Perl腳本語言開發及徹底開源
  2. 能夠支持就GTID的複製模式
  3. MHA在進行故障轉移時不容易產生數據丟失
  4. 同一個監控節點能夠監控多個集羣

》MMM集羣的缺點：

  1. 須要編寫腳本或利用第三方工具（keepalive等等）來實現VIP的配置
  2. MHA啓動後只會對主數據庫進行監控
  3. 須要基於SSH免認證配置，存在必定的安全隱患
  4. 沒有提供從服務器的讀負載均衡的功能

數據庫的讀寫分離（如何在複製集羣的不一樣角色上，去執行不一樣的SQL語句）

程序實現的讀寫分離

優勢：由開發人員控制什麼樣的查詢再從庫上來執行，所以比較靈活
	 由程序直接鏈接誒數據庫，因此性能損耗比較少

缺點：增長了開發的工做量，使得程序代碼更爲複雜人爲控制，
	 容易出現錯誤
複製代碼

中間件的讀寫分離(mysql-proxy、maxScale)

優勢：中間件根據查詢語法的分析，自動完成讀寫分離；
	 對程序透明，對已有的程序不用作任何的調整。

缺點：增長了中間層，因此對查詢效率有損耗；
	 對於延遲敏感業務沒法在主庫上執行
複製代碼

實現讀的負載均衡（具備相同角色的數據庫，如何共同分擔相同的負載）

軟件：LVS、Haproxy、MaxScale

硬件：F5

maxScale插件:

maxScale插件體系結構

  1. Authentication 認證插件
  2. Protocal 協議插件
  3. Router 路由插件（readconnroute、readwritesplit）
  4. MOnitor 監控插件
  5. Filter&Logging 日誌和過濾插件

maxScale實現讀寫分離及負載均衡

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程