性能達到瓶頸的解決方案html
MySQL擴展采用的方式讀寫分離
將數據庫的訪問拆分紅兩種訪問,讀(select)和寫(增刪改),經過調度器,將用戶的不一樣請求分別發送給讀服務器或者寫服務器,在寫服務器增長數據時,須要使用主從複製機制來同步數據到讀服務器前端
主從複製特徵node
主從複製的功用mysql
讀寫分離應用:git
主從複製原理
github
MySQL垂直分區
web
MySQL水平分片(Sharding)
算法
主從複製架構:sql
主從配置官網資料
https://mariadb.com/kb/en/library/setting-up-replication/
https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.htmlshell
主節點配置
log_bin
:啓用二進制日誌,在mariadb配置文件,[mysqld]內添加項 server_id=#
:爲當前節點設置一個全局唯一的ID號,判斷數據來源的標識,[mysqld]內添加項log-basename=master
:設置datadir中日誌名稱sync_binlog=1
: 每次寫後當即同步二進制日誌到磁盤,性能差innodb_flush_log_at_trx_commit=1
: 每次事務提交當即同步日誌寫磁盤innodb_support_xa=ON
: 默認值,分佈式事務MariaDB10.3.0廢除sync_master_info=#
:#次事件後master.info同步到磁盤REPLICATION SLAVE
:給予從服務器的權限,只能夠同步複製二進制日誌repluser
:用戶帳號命名HOST
:從服務器IP或網段IDENTIFIED BY
:設置口令關鍵字從節點配置:
配置文件
server_id=#
:爲當前節點設置一個全局唯的ID號relay_log=relay-log
:中繼日誌的文件路徑,默認值文件名爲hostname-relay-binrelay_log_index=relay-log.index
:中繼日誌索引文件路徑,默認值hostname-relay-bin.indexskip_slave_start=ON
:不自動啓動slavesync_relay_log=#
:#次寫後同步relay log到磁盤sync_relay_log_info=#
:#次事務後同步relay-log.info到磁盤使用有複製權限的用戶帳號鏈接至主服務器,並啓動複製線程
複製架構中應該注意的問題
read_only=ON
mysql> FLUSH TABLES WITH READ LOCK;
STOP SLAVE
RESET SLAVE ALL
sql_slave_skip_counter = N
理論上應該保持主從服務器版本一致,避免出現未知錯誤
主從複製
已經有主從服務器,額外添加一個從服務器
--master-data=1
選項,會自動在備份文件中加入CHANGE MASTER TO
關鍵詞,修改徹底備份文件,在導入時備份文件時,使其能夠直接執行從服務器同步複製指令若是主服務器A宕機,在從服務器(B、C)中,選一個來充當主服務器
級聯複製,給從服務器B再下設從服務器C
主從複製依賴的是二進制日誌文件,而從服務器接收主服務器的二進制文件經過中繼日誌執行寫入磁盤,不會產生新的二進制日誌(二進制日誌產生是對數據庫直接進行增刪改),想要在從服務器生成二進制文件供級聯使用,就須要在配置文件中加入選項log_slave_updates
主服務器爲A,從服務器爲B,從服務器的下設從服務器爲C;在從服務器B上修改配置文件,開啓二進制日誌功能,重啓服務,查看二進制日誌位置
在C上設置從服務器設置,修改配置文件,設置惟一id,設只讀設置等,而後進入mysql設置從服務器,將主機指向B
容易產生的問題
數據同步有延遲,兩主機可能修改的是同一個數據,容易衝突;所以慎用
考慮要點:自動增加id
主主複製的配置步驟:
默認狀況下,MySQL的複製功能是異步的,異步複製能夠提供最佳的性能,主庫把binlog日誌發送給從庫即結束,並不驗證從庫是否接收完畢。
因爲MySQL的複製內在機制,可能會產生比較大的延遲,這意味着當主服務器或從服務器端發生故障時,有可能從服務器沒有接收到主服務器發送過來的binlog日誌,這就會形成主服務器和從服務器的數據不一致,甚至在恢復時形成數據的丟失;而同步方式效率又不高。
rpl_semi_sync_master
,這個插件表現爲庫so文件/usr/lib64/mysql/plugin/semisync_master.so
/usr/lib64/mysql/plugin/semisync_slave.so
讓從節點僅複製指定的數據庫,或指定數據庫的指定表
服務器選項:主服務器僅向二進制日誌中記錄與特定數據庫相關的事件
注意:此項和binlog_format相關,基於二進制還原將沒法實現;不建議使用
參看:https://mariadb.com/kb/en/library/mysqld-options/#-binlog-ignore-db
binlog-do-db = 數據庫白名單列表,多個數據庫需多行實現
binlog-ignore-db = 數據庫黑名單列表
從服務器SQL_THREAD在replay中繼日誌中的事件時,僅讀取與特定數據庫(特定表)相關的事件並應用於本地
問題:會形成網絡及磁盤IO浪費
示例,在從服務器上在白名單中添加數據庫hellodb,只能對進入庫操做起做用,須要use hellodb
進入數據庫,改變數據後從服務器才能同步,hellodb.teacher寫法會被過濾掉
在默認的主從複製過程或遠程鏈接到MySQL/MariaDB全部的連接通訊中的數據都是明文的,外網裏訪問數據或則複製,存在安全隱患。經過SSL/TLS加密的方式進行復制的方法,來進一步提升數據的安全性
配置實現:
參看:https://mariadb.com/kb/en/library/replication-with-secure-connections/
配置示例
require ssl
8 主從複製的監控和維護
- 清理日誌
- 刪除指定部分二進制日誌
- 刪除二進制日誌信息
- 刪除從服務器信息
- 主從複製監控
- 查看當前二進制日誌位置,白名單和黑名單
- 查看二進制日誌記錄詳細內容
- 查看全部二進制日誌大小及位置
- 查看從服務器同步複製信息
- 顯示哪些鏈接線程正在運行
- 從服務器是否落後於主服務,在列表中
- 如何肯定主從節點數據是否一致
- 數據不一致如何修復
刪除從數據庫,從新複製9 MySQL高可用-集羣架構
9.1 集羣概述
實現高可用性解決方案
MHA集羣架構
主服務器宕機緣由
爲了儘量的減小主庫硬件損壞宕機形成的數據丟失,所以在配置MHA的同時建議配置成MySQL 5.5的半同步複製
MHA軟件由兩部分組成,Manager工具包和Node工具包
工具 | 功能描述 |
---|---|
masterha_check_ssh | 檢查MHA的SSH配置情況 |
masterha_check_repl | 檢查MySQL複製情況 |
masterha_manger | 啓動MHA |
masterha_check_status | 檢測當前MHA運行狀態 |
masterha_master_monitor | 檢測master是否宕機 |
masterha_master_switch | 故障轉移(自動或手動) |
masterha_conf_host | 添加或刪除配置的server信息 |
工具 | 功能描述 |
---|---|
save_binary_logs | 保存和複製master的二進制日誌 |
apply_diff_relay_logs | 識別差別的中繼日誌事件並將其差別的事件應用於其餘的slave |
filter_mysqlbinlog | 去除沒必要要的ROLLBACK事件(MHA已再也不使用此工具) |
purge_relay_logs | 清除中繼日誌(不會阻塞SQL線程) |
工具包安裝位置
MHA集羣搭建
vim /etc/mastermha/app1.cnf [server default] user=mhauser <==MHA服務器管理各主從服務器使用的帳號 password=magedu <==MHA服務器密碼 manager_workdir=/data/mastermha/app1/ <==工做目錄 manager_log=/data/mastermha/app1/manager.log <==日誌 remote_workdir=/data/mastermha/app1/ <==被管理節點上manager的工做目錄,自動生成 ssh_user=root <==主服務器上設置的管理員權限的帳號,用來讀取日誌、提高從服務器等 repl_user=repluser <==複製數據的帳號密碼 repl_password=magedu ping_interval=1 <==1秒監控一次服務器是否正常工做 [server1] <==被管理的服務器 hostname=192.168.8.17 candidate_master=1 <==能夠充當master的從服務器,人爲定義充當主服務器 [server2] hostname=192.168.8.27 candidate_master=1 [server3] hostname=192.168.8.37
自定義擴展選項
secondary_check_script: ‘經過多條網絡路由檢測master的可用性’
master_ip_ailover_script: ‘更新Application使用的masterip’
shutdown_script: ‘強制關閉master節點’
report_script: ‘發送報告’
init_conf_load_script: ‘加載初始配置參數’
master_ip_online_change_script:‘更新master節點ip地址’
1. '修改配置文件' vim /etc/my.cnf [mysqld] log-bin server_id=1 skip_name_resolve=1 <==在MHA中,反向解析爲強制項 2. '查看二進制文件,備用配置從服務器' mysql>show master logs 3. '建立從服務器複製權限帳號' mysql>grant replication slave on *.* to repluser@'192.168.8.%' identified by 'magedu'; 4. '建立高權限帳號查看二進制與提高從服務器' mysql>grant all on *.* to mhauser@'192.168.8.%’identified by‘magedu';
示例
在全部節點實現相互之間ssh key驗證
實現主從關係
配置MHA,須要epel源,須要的工具包和
- 在manage管理端兩個都要安裝
- 1
- 2
測試manage,自動提高從服務器功能,宕掉主服務器
集成了Galera插件的MySQL集羣,是一種新型的,數據不共享的,高度冗餘的高可用方案;
目前Galera Cluster有兩個版本,分別是Percona Xtradb Cluster及MariaDB Cluster,Galera自己是具備多主特性的,即採用multi-master的集羣架構,是一個既穩健,又在數據一致性、完整性及高性能方面有出色表現的高可用解決方案
如圖示:三個節點組成了一個集羣,與普通的主從架構不一樣,它們均可以做爲主節點,三個節點是對等的,稱爲multi-master架構,當有客戶端要寫入或者讀取數據時,鏈接哪一個實例都是同樣的,讀到的數據是相同的,寫入某一個節點以後,集羣本身會將新數據同步到其它節點上面,這種架構不共享任何數據,是一種高冗餘架構想
同步複製與異步複製
同步複製優缺點
解決同步複製中的缺點
Galera集羣使用的基於證書的複製系統就是創建如下方法之上的
基於認證的複製須要什麼
Galera Cluster特色
Galera Cluster工做過程
Galera Cluster官方文檔:
http://galeracluster.com/documentation-webpages/galera-documentation.pdf
http://galeracluster.com/documentation-webpages/index.html
https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/
Galera Cluster包括兩個組件
WSREP複製實現:
至少須要三個節點,不能安裝mariadb-server
查看集羣中相關係統變量和狀態變量
Galera Cluster實現步驟
安裝,須要配置yum源,這裏使用清華的yum源
修改配置文件
下面爲配置可選項
wsrep_cluster_name = ‘mycluster‘默認my_wsrep_cluster <==集羣名稱
wsrep_node_name = ‘node1’ <==自定義節點名稱
wsrep_node_address = ‘192.168.8.7’
首次啓動時,須要初始化集羣,在其中一個節點上執行腳本mysql
mysql腳原本自安裝包
在其中一個節點上運行此腳本,後面跟start --wsrep-new-cluster
表示開啓新的組,後續的節點只要啓動服務便可
數據庫服務衡量指標:
壓力測試工具
MYSQL壓力測試工具Mysqlslap
來自於mariadb包,測試的過程默認生成一個mysqlslap的schema,生成測試表t1,查詢和插入測試數據,mysqlslap庫自動生成,若是已經存在則先刪除。用–only-print來打印實際的測試過程,整個測試完成後不會在數據庫中留下痕跡
--auto-generate-sql, -a
--auto-generate-sql-load-type=type
--auto-generate-sql-add-auto-increment
--number-char-cols=N, -x
--number-int-cols=N, -y
--number-of-queries=N
--query=name,-q
--create-schema
--commint=N
--compress, -C
--concurrency=N, -c
--concurrency=100,200,500
--engine=engine_name, -e engine_name
--iterations=N, -i
--only-print
--detach=N
--debug-info, -T
示例
mysqlslap -a -uroot -pmagedu
mysqlslap -a -c 100 -uroot -pmagedu
--number-of-queries 1000
:查詢一千次--concurrency=50,100
:併發50和100分別測試--iterations=5
:迭代5次--engine=myisam,innodb
:分別對myisam,innodb引擎測試高併發大數據的互聯網業務,架構設計思路是「解放數據庫CPU,將計算轉移到服務層」,併發量大的狀況下,這些功能極可能將數據庫拖死,業務邏輯放到服務層具有更好的擴展性,可以輕易實現「增機器就加性能」
'硬件:內存32G' innodb_file_per_table = 1 '打開獨立表空間' max_connections = 8000 'MySQL服務所容許的同時會話數的上限,常常出現Too Many Connections的錯誤提示,則須要增大此值,根據服務器性能判斷,防止設置過大超過承載能力崩潰' back_log = 300 'back_log 是操做系統在監聽隊列中所能保持的鏈接數,也就是最大會話數上限後,等待數上限' max_connect_errors = 1000 '每一個客戶端鏈接最大的錯誤容許數量,當超過該次數,MYSQL服務器將禁止此主機的鏈接請求,直到MYSQL服務器重啓或經過flush hosts命令清空此主機的相關信息' open_files_limit = 10240 '全部線程所打開表的數量' max_allowed_packet = 32M '每一個鏈接傳輸數據大小.最大1G,須是1024的倍數,通常設爲最大的BLOB的值' wait_timeout = 10 '指定一個請求的最大鏈接時間,超時時長' sort_buffer_size = 16M '排序緩衝被用來處理相似ORDER BY以及GROUP BY隊列所引發的排序' join_buffer_size = 16M '不帶索引的全表掃描.使用的buffer的最小值' query_cache_size = 128M '查詢緩衝大小' query_cache_limit = 4M '指定單個查詢可以使用的緩衝區大小,缺省爲1M' transaction_isolation = REPEATABLE-READ '設定默認的事務隔離級別' thread_stack = 512K '線程使用的堆大小. 此值限制內存中能處理的存儲過程的遞歸深度和SQL語句複雜性,此容量的內存在每次鏈接時被預留.' log-bin '二進制日誌功能' binlog_format=row '二進制日誌格式' innodb_buffer_pool_size = 24G 'InnoDB使用一個緩衝池來保存索引和原始數據, 可設置這個變量到服務器物理內存大小的80%' innodb_file_io_threads = 4 '用來同步IO操做的IO線程的數量' innodb_thread_concurrency = 16 '在InnoDb核心內的容許線程數量,建議的設置是CPU數量加上磁盤數量的兩倍' innodb_log_buffer_size = 16M '用來緩衝日誌數據的緩衝區的大小' innodb_log_file_size = 512M '在日誌組中每一個日誌文件的大小' innodb_log_files_in_group = 3 '在日誌組中的文件總數' innodb_lock_wait_timeout = 120 'SQL語句在被回滾前,InnoDB事務等待InnoDB行鎖的時間' long_query_time = 2 '慢查詢時長' log-queries-not-using-indexes '將沒有使用索引的查詢也記錄下來'