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

1. MySQL 常見發行版本
2. MySQL 標准化、自動化部署
3. 深入淺出MySQL備份與恢復
4. 深入理解MySQL主從復制
5. MySQL構架設計與容量規划
6. MHA
7. 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

• 數據目錄 ---> SSD
• 日志目錄 ---> SAS

自動化部署

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)

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

熱備(MySQL服務器OPEN)

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

備份有效性測試

自動化備份設計

MySQL 備份工具

1. 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

2. 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

3. xtrabackup

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

Xtrabackup 安裝

1. rpm包安裝

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

2. yum源安裝

yum install percona-xtrabackup

3. 源碼安裝

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就是保證主庫將日志先傳輸到備庫，然后再返回給應用事務提交成功，流程如下:

主從復制常見問題

• 主庫掛了，怎么判斷從庫是否同步完成？
• 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文檔

讀寫分離方案

海量數據的存儲及訪問，通過對數據庫進行讀寫分離，來提升數據的處理能力。讀寫分離它的方案特點是數據庫產生多個副本，數據庫的寫操作都集中到一個數據庫上，而一些讀的操作呢，可以分解到其它數據庫上。這樣，只要付出數據復制的成本，就可以使得數據庫的處理壓力分解到多個數據庫上，從而大大提升數據處理能力。
優點：由於所有的數據庫副本，都有數據的全拷貝，因此所有的數據庫特性都可以實現，部分機器當機不影響系統的使用。
缺點：數據的復制同步是一個問題，要么采用數據庫自身的復制方案，要么自行實現數據復制方案。需要考慮數據的遲滯性，一致性方面的問題。

數據分區方案

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

數據分表方案

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

分表的兩種方案

• 單庫單表無法滿足大量寫的請求

1. 同庫分表：所有的分表都在一個數據庫中，由於數據庫中表名不能重復，因此需要把數據表名起成不同的名字。
   優點：由於都在一個數據庫中，公共表，不必進行復制，處理更簡單
   缺點：由於還在一個數據庫中，CPU、內存、文件IO、網絡IO等瓶頸還是無法解決，只能降低單表中的數據記錄數。表名不一致會導后續的處理復雜。

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

同庫分表(分表)

不同庫分表(分庫)

訂單分庫分表

混合方案

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

實現線路分析

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

分庫分表帶來的限制

1. 條件查詢、分頁查詢受到限制，查詢必須帶上分庫分表所帶上的id
2. 事務可能跨多個庫，數據一致性無法通過本地事務實現，無法使用外鍵
3. 分庫分表規則確定以后，擴展變更規則需要遷移數據

業務痛點

、

業內解決方案

	來源	血緣	類型
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支持主從同步延遲檢測功能。

MariaDB MaxScale - 基於connect

MariaDB MaxScale - 兩種模式解釋

用maxscale做多台slave的負載均衡，從而取代haproxy

大多數公司架構：一個主庫，多個從庫，主庫寫，從庫負責查詢，主庫的ha通過MHA實現，從庫讀的負載均衡通過lvs或者haproxy實現（JAVA框架和PHP框架實現讀寫分離）

MariaDB MaxScale - 基於SQL解析

maxscale 安裝

見 文檔