MHA + Maxscale 數據庫的高可用和讀寫分離

時間 2020-06-03

原文原文鏈接

MySQL 常見發行版本
MySQL 標準化、自動化部署
深刻淺出MySQL備份與恢復
深刻理解MySQL主從複製
MySQL構架設計與容量規劃
MHA
Maxscale

MySQL 常見發行版本

Mysql 官方
Percona
Mariadb

MySQL 標準化、自動化部署

1. 機器標準化
2. 參數標準化
3. 統一安裝包
4. 目錄標準化
5. 多實例部署
6. 自動化部署

機器標準化

CPU
Memory
SSD
SAS

參數標準化

統一安裝包

1. 源碼包
2. rpm
3. 二進制

目錄標準化

數據目錄	日誌目錄	binlog
data	logs	binlog

多實例部署

實例	u01	u02	u03	u04
端口	3306	3307	3308	3309
數據目錄	/data/3306/data	/data/3307/data	/data/3308/data	/data/3309/data
日誌目錄	/data/3306/logs	/data/3307/logs	/data/3308/logs	/data/3309/logs
硬盤容量	500G+100G	500G+100G	500G+100G	500G+100G

自動化部署

1. 打通SSH互信(saltstack、Ansible、puppet)
2. 修改主機名(惟一)
3. 建立並掛載目錄
4. 安裝agent端（salt-minion）
5. 安裝zabbix agent端
6. 安裝MySQL並加載監控項
7. 調整MySQL 參數（port、server_id、innodb_buffer_pool_size）
8. 啓動MySQL 初始化環境（管理用戶、查詢用戶、監控用戶）

MySQL 安裝步驟

關閉防火牆
配置sysctl.conf
檢查操做系統上是否安裝了MySQL
下載mysql源碼包
添加用戶和組
配MySQL環境變量
建立目錄及受權
解壓mysql5.6
MySQL參數配置
初始化MySQL腳本
啓動MySQL 
登陸MySQL

深刻淺出MySQL備份與恢復

備份恢復的使用場景
備份類型
備份有效性測試
自動化備份設計
MySQL備份工具
Xtrabackup安裝
Xtrabackup備份實現
innobackupex整個備份過程
innobackupex恢復原理
Innobackupex備份恢復演示

備份恢復的使用場景

監管要求
搭建備庫
異常恢復

備份類型

熱備
冷備
溫備

邏輯備份

1. 邏輯備份將數據庫的內容轉儲到文本文件中
2. 這些文本文件包含 SQL 語句，這些 SQL 語句包含重建MySQL 數據庫和表所需的所有信息
3. 可使用該文本文件在運行不一樣體系結構的其餘主機上從新裝入數據庫
4. 在建立邏輯備份時，MySQL 服務器必須處於運行狀態，由於服務器在建立文件時要讀取備份的表的結構和內容
5. 採用邏輯備份時，能夠備份本地和遠程的 SQL 服務器。只能在本地 MySQL 服務器上執行其餘類型的備份

物理備份

1. 物理備份是 MySQL 數據庫文件的二進制副本。這些副本以徹底相同的格式保留數據庫存儲在磁盤上;
2. 原始備份是數據庫文件位的完整表現形式，所以必須將其恢復到使用相同數據庫引擎的MySQL 服務器;
3. 在從 InnoDB 表恢復原始 MySQL 備份時，會在目標服務器上保留一個 InnoDB 表;
4. 原始二進制備份的速度比邏輯備份快，由於該過程是簡單的文件複製，不須要了解文件的內部結構

冷備與熱備(物理備份)

冷備(MySQL服務器CLOSE)php

1. 可經過關閉 MySQL 服務器，而後再進行備份
2. 備份時，必須確保在備份進行期間服務器不修改文件

熱備(MySQL服務器OPEN)html

1. 可使用快照、複製或專有方法，最大限度地減少對 MySQL 和應用程序的影響
2. 對於某些存儲引擎，更好的辦法是暫時鎖定數據庫，進行備份，而後再將數據庫解鎖,鎖在熱備作了兩件事：第一記錄binlog文件的位置、第二冷備非事務引擎引的表(MYISAM)

備份有效性測試

自動化備份設計

MySQL 備份工具

mysqldump

# mysqldump工具使用
1. mysqldump --help
2.mysqldump -h127.0.0.1 -P3306 -uroot  -p --single-transaction  linux > /tmp/linux.sql
# 分析mysqldump流程
打開general.log————>執行mysqldump————>分析general.log————>關閉general.log

mysqlduper

# 下載
https://launchpad.net/mydumper
# 編譯安裝
cmake .
make 
make install
# mysqldumper 備份
mydumper  --user=root  --password='123456' --socket=/tmp/mysql3306.sock --regex '^(?!(mysql))'  --outputdir=/u01/backup/ --compress --verbose=3  --logfile=/apps/backup/mydumper.log

xtrabackup

1. Xtrabackup是由percona提供的mysql數據庫備份工具，據官方介紹，這也是世界上唯一一款開源的可以對innodb和xtradb數據庫進行熱備的工。
Xtrabackup中主要包含兩個工具：
	1. xtrabackup：是用於熱備份innodb, xtradb表中數據的工具，不能備份其餘類型的表，也不能備份數據表結構.
	2. innobackupex：是將xtrabackup進行封裝的perl腳本，能夠備份和恢復MyISAM表以及數據表結構。

Xtrabackup 安裝

rpm包安裝

rpm -Uvh https://www.percona.com/downloads/XtraBackup/LATEST/percona-xtrabackup-24-2.4.5-1.el6.x86_64.rpm

yum源安裝

yum install percona-xtrabackup

源碼安裝

1. 解壓源碼包
tar -xzvf percona-xtrabackup-2.1.7.tar.gz 
2. 安裝perl環境(DBI/DBD)
yum install perl-DBIx-Simple.noarch perl-DBD-MySQL.x86_64  perl*

3. Prerequisites
yum -y install cmake gcc gcc-c++ libaio libaio-devel automake autoconf bison libtool ncurses-devel libgcrypt-devel libev-devel

4. 開始編譯
./utils/build.sh	#根據版本確認build.sh的參數
./utils/build.sh innodb56	#開始編譯
5.把xtrabackup_5.6複製到/usr/bin下
cp /u01/percona-xtrabackup-2.1.7/src/xtrabackup_56 /usr/bin/

Xtrabackup 備份實現

innobackupex 整個備份過程

innobackupex 恢復原理

innobackupex備份恢復演練

深刻理解MySQL主從複製

主從複製的架構
線上快速搭建主從複製
主從複製的詳細過程分析
主從複製相關參數
Semi-sync複製
主從複製常見問題

主從複製的架構

線上快速搭建主從複製流程

線上快速搭建主從複製命令

Master上建立複製帳號並受權
grant replication slave,replication client on *.* to repl@'%' identified by ‘password’;
Master、Slave上分別設置不一樣的Server_id  vim my.cnf; set global server_id=xxxxx;
Master上執行一次完整邏輯（物理）備份	#ibbackup, xtrabackup, mysqldump  mysqldump	--single-transaction --master-data
Slave上，拿到Master全備在Slave作一次全量恢復
Slave上執行CHANCE MASTER配置主從複製  Slave上執行Start slave啓動複製
start slave;
show slave status\G

主從複製的詳細過程分析

主從複製相關參數

# Master
server-id
read_only  
mysql_log_bin
binlog_format
binlog_cache_size
max_binlog_size  
expire_logs_days  
binlog-do-db  
binlog-ignore-db
#Slave
server-id
read_only
sql_log_bin
log_slave_updates
replicate-do-db  
replicate-ignore-db
replicate-do-table
replicate-ignore-table

Binlog日誌格式

SBR(statement based replicate)

每一條會修改數據的sql都會記錄在binlog中
優勢：
不須要記錄每一行的變化，減小了
binlog日誌量，節約了IO，提升性能。
缺點：
因爲記錄的只是執行語句，爲了這些語  句能在slave上正確運行，所以還必須  記錄每條語句在執行的時候的一些相關  信息，以保證全部語句能在slave獲得  和在master端執行時候相同 的結果。  另外mysql 的複製,像一些特定函數功  能，slave可與master上要保持一致會  有不少相關問題(如now()函數，  sysdate()，以及uuid()會出現問題).

RBR （row based replicate）

不記錄sql語句上下文相關信息，僅保存哪條記錄
被修改。
優勢
binlog僅須要記錄那一條記錄被修改爲什麼了。
因此row模式的日誌內容會很是清楚的記錄下每一  行數據修改的細節。並且不會出現某些特定狀況  下的存儲過程，或function，以及trigger的調用  和觸發沒法被正確複製的問題.
缺點
全部的執行的語句當記錄到日誌中的時候，都  將以每行記錄的修改來記錄，這樣可能會產生大  量的日誌內容,好比一條update語句，修改多條記  錄，則binlog中每一條修改都會有記錄，這樣造  成binlog日誌量會很大.
從數據的安全性考慮出發，推薦使用row模式。

Mixed

結合SBR與RBR  一般使用SBR  非肯定狀況使用RBR
是row和statement模式的混合使用，通常的語句
修改使用statment格式保存binlog，如一些函數，  statement沒法完成主從複製的操做，則採用row  格式保存binlog,MySQL會根據執行的每一條具體  的sql語句來區分對待記錄的日誌形式，也就是在  Statement和Row之間選擇一種.具體的能夠參看  官方的文檔:  http://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html

Semi-sync複製

Semi-sync最先是由Google實現的一個補丁，代碼主要由Mark Callaghan、Wei Li（@Google）等人貢獻。Google本來是將需求提給Hekki的，可是後來等不及就本身實現了。5.5版本正式合併到官方的版本。
Semi-sync就是保證主庫將日誌先傳輸到備庫，而後再返回給應用事務提交成功，流程以下:
java

主從複製常見問題

主庫掛了，怎麼判斷從庫是否同步完成？
mysql主從庫同步錯誤：1032/1062/1060 Error
主從的UUID重複的錯誤 Slave_IO_Running: No Slave_SQL_Running: Yes
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

MySQL構架設計與容量規劃

MySQL構架設計
容量評估
Sysbench壓測
業務痛點
讀寫分離方案
數據分區方案
分表的兩種方案
混合方案
實現路線分析
業內解決方案

MySQL構架設計

容量評估

容量評估——QPS評估

峯值qps=(總的pv * 80%)/(60 * 60 * 24 *20%)
機器數=總的峯值qps/壓測得出的單臺機器極限qps

Sysbench 壓測

見sysbench安裝及性能測試.docx文檔mysql

讀寫分離方案

海量數據的存儲及訪問，經過對數據庫進行讀寫分離，來提高數據的處理能力。讀寫分離它的方案特色是數據庫產生多個副本，數據庫的寫操做都集中到一個數據庫上，而一些讀的操做呢，能夠分解到其它數據庫上。這樣，只要付出數據複製的成本，就可使得數據庫的處理壓力分解到多個數據庫上，從而大大提高數據處理能力。
優勢：因爲全部的數據庫副本，都有數據的全拷貝，所以全部的數據庫特性均可以實現，部分機器當機不影響系統的使用。
缺點：數據的複製同步是一個問題，要麼採用數據庫自身的複製方案，要麼自行實現數據複製方案。須要考慮數據的遲滯性，一致性方面的問題。linux

數據分區方案

原來全部的數據都是在一個數據庫上的，網絡IO及文件IO都集中在一個數據庫上的，所以CPU、內存、文件IO、網絡IO均可能會成爲系統瓶頸。而分區的方案就是把某一個或某幾張相關的表的數據放在一個獨立的數據庫上，這樣就能夠把CPU、內存、文件IO、網絡IO分解到多個機器中，從而提高系統處理能力。
優勢：不存在數據庫副本複製，性能更高。
缺點：分區策略必須通過充分考慮，避免多個分區之間的數據存在關聯關係，每一個分區都是單點，若是某個分區宕機，就會影響到系統的使用。c++

數據分表方案

無論是上面的讀寫分離方案仍是數據分區方案，當數據量大到必定程度的時候，都會致使處理性能的不足，這個時候就沒有辦法了，只能進行分表處理。也就是把數據庫當中數據根據按照分庫原則分到多個數據表當中，這樣，就能夠把大表變成多個小表，不一樣的分表中數據不重複，從而提升處理效率。
優勢：數據不存在多個副本，沒必要進行數據複製，性能更高。
缺點：分表之間的數據不多進行集合運算；分表都是單點，若是某個分表宕機，若是使用的數據不在此分表，不影響使用。sql

分表的兩種方案

單庫單表沒法知足大量寫的請求

同庫分表：全部的分表都在一個數據庫中，因爲數據庫中表名不能重複，所以須要把數據表名起成不一樣的名字。
優勢：因爲都在一個數據庫中，公共表，沒必要進行復制，處理更簡單
缺點：因爲還在一個數據庫中，CPU、內存、文件IO、網絡IO等瓶頸仍是沒法解決，只能下降單表中的數據記錄數。表名不一致會導後續的處理複雜。

不一樣庫分表：因爲分表在不一樣的數據庫中，這個時候就可使用一樣的表名。
優勢：CPU、內存、文件IO、網絡IO等瓶頸能夠獲得有效解決，表名相同，處理起來相對簡單
缺點：公共表因爲在全部的分表都要使用，所以要進行復制、同步。

同庫分表(分表)

不一樣庫分表(分庫)

訂單分庫分表

混合方案

經過上面的描述，咱們理解了讀寫分離，數據分區，數據分表三個解決方案，實際上都各有優勢
，也各有缺，所以，實踐當中，會把三種方案混合使用。因爲數據一天比一天長多，實際上，在剛開始的時候，可能只採用其中一種方案，隨着應用的複雜，數據量的增加，會逐步採用多個方案混合的方案。以提高處理能力，避免單點。shell

實現線路分析

正所謂條條大路通羅馬，解決這個問題的方案也有多種，但究其深源，均可以歸到兩種方案之上，一種是對用戶透明的方案，即用戶只用像普通的J
DBC數據源同樣訪問便可，由框架解決全部的數據訪問問題。另一種是應用層解決，具體通常是在Dao層進行封裝。
JDBC層方案
優勢：開發人員使用很是方便，開發工做量比較小；能夠實現數據庫無關。
缺點：框架實現難度比較大，性能不必定能作到最優。一樣是JDBC方案，也有兩種解決方案，一種是有代理模式，一種是無代理模式。
有代理模式，有一臺專門的代理服務器，來接收用戶請求，而後發送請求給數據庫集羣中的數據，並對數據進行聚集後再提交給請求方。無代理模式，就是說沒有代理服務器，集羣框架直接部署在應用訪問端。有代理模式，可以提供的功能更強大，甚至可買提供中間庫進行數據處理，無代理模式處理性能較強有代理模式少一次網絡訪問，相對來講性能更好，可是功能性不若有代理模式。
DAO層方案
優勢：開發人員自由度很是大，性能調優更精準。
缺點：開發人員在必定程度上受影響，與具體的Dao技術實現相關，較難作到數據庫無關。因爲須要對SQL腳本進行判斷，而後進行路由，所以DAO層優化方案通常都是選用iBatis或Spring Jdbc Template等方案進行封裝，而對於Hibernate等高度封裝的OR映射方案，實現起來就很是困難了。數據庫

分庫分錶帶來的限制

條件查詢、分頁查詢受到限制，查詢必須帶上分庫分表所帶上的id
事務可能跨多個庫，數據一致性沒法經過本地事務實現，沒法使用外鍵
分庫分表規則肯定之後，擴展變動規則須要遷移數據

業務痛點

、vim

業內解決方案

	來源	血緣	類型
Cobar	阿里		中間件
TDDL	阿里		客戶端二方庫
DRDS	阿里	Cobar、TDDL	分佈式數據庫
MyCAT	社區	Cobar	中間件
Atlas	360	MySQL Proxy	中間件
TDSQL	騰訊	MySQL Proxy	分佈式數據庫
Heisenberg	百度	Cobar	中間件
藍海豚	京東	MySQL Proxy	中間件
Mxscale	Mariadb		中間件

MHA

MHA 簡介

MHA，是日本的一位MySQL專家採用Perl語言編寫的一個腳本管理工具，目的在於維持MySQL Replication中Master庫的高可用性，其最大特色是可以修復多個Slave之間的差別日誌，最終使全部Slave保持數據一致，而後從中選擇一個充當新的Master，並將其它Slave指向它。

MHA集羣架構

MHA 監控

每ping_interval秒監控master一次 MHA自身提供了兩種監控方式：SELECT和 CONNECT，控制參數ping_type

•調用SSH腳本對全部Node執行檢查，包括
  •Master服務器是否能夠SSH連通
  •MySQL實例是否能夠鏈接
  •檢查SQL Thread的狀態
  •檢查哪些Server死掉了，哪些Server是活動  的，以及活動的Slave實例
  •檢查Slave實例的配置及複製過濾規則

1.SQL Thread alive?	NO: Restart it
2.調用master_ip_failover_script關閉VIP
3.檢查各個Slave，獲取最近的和最舊的  binary log file和position，並檢查各個  Slave成爲Master的優先級
4.若dead master所在服務器依然能夠經過SSH連通，  則提取dead master的binary log。另外，MHA還要  對各個Slave節點SSH連通性進行檢查。
5.調用apply_diff_relay_logs命令恢復Slave的差別日誌，  即各個Slave之間的relay log
6.差別日誌恢復到New Master上，而後獲取New Master的binlog name和
position，最後會開啓New Master的寫權限
7.清理New Master其實就是重置slave info，即取消原來的Slave信息

MySQL Master Crash

恢復過程

Saving binlog events from (crashed) master

Understanding SHOW SLAVE STATUS

Identifying the latest slave

Identifying what events need to be applied

MHA部署實戰

MHA部署.txt 文檔

Maxscale

maxscale有兩種方式實現讀寫分離。一種是基於connect的，相似haproxy，不解析sql語句。另外一種是statement，基於解析sql語句的。解析sql勢必會增長性能損耗，咱們能夠經過php yii框架或者java mybatis框架實現讀寫分離，基於connect方式，用maxscale作多臺slave的負載均衡，從而取代haproxy。若是開發實現困難，那麼採用statement方式。
注: maxscale支持主從同步延遲檢測功能。