MySQL 故障篇
一、開(kāi)QC，導(dǎo)致性能降低，QPS，TPS降低
QC在分區(qū)表中是不起作用的。
二、Mysql連接長(zhǎng)時(shí)間（7200和1200秒）無(wú)法釋放
ipvsadmin -l -timeout 查看LVS的超時(shí)時(shí)間
Timeout (tcp tcpfin udp ): 90 120 300
net.ipv4.tcp_keepalive_time = 60 設(shè)置每隔60秒大宋一個(gè)心跳包，探測(cè)是否斷開(kāi)。
pt-kill殺死連接時(shí)間較長(zhǎng)的連接
三、過(guò)度條帶化導(dǎo)致性能問(wèn)題
LVM條帶化+raid5導(dǎo)致的 IOPS過(guò)高
四、有規(guī)律的一段時(shí)間，會(huì)產(chǎn)生性能低估
RAID卡巡讀，一致性檢查或電池充放電導(dǎo)致的性能下降。
五、zabbix監(jiān)控2000+臺(tái)主機(jī)，監(jiān)控顯示緩慢，每隔三四個(gè)月重新搭建，存儲(chǔ)空間經(jīng)常被占滿(mǎn)
1.升級(jí)zabbix到最新版本，數(shù)據(jù)按月份切割。
2.升級(jí)數(shù)據(jù)庫(kù)版本
3.使用tokudb引擎
4.分區(qū)表
為什么？
1.tokudb插入數(shù)據(jù)要比innodb快，數(shù)據(jù)壓縮比innodb高
2.監(jiān)控?cái)?shù)據(jù)按月進(jìn)行切割，為了能夠truncate每個(gè)分區(qū)表，立即釋放空間
3.關(guān)閉binlog 減少無(wú)關(guān)日志記錄
4.參數(shù)調(diào)整，安全性參數(shù)關(guān)閉，提高性能
六、由于宕機(jī)，導(dǎo)致主從不一致，如何解決
1.pt工具可以修復(fù)主從不一致的問(wèn)題
2.主庫(kù)啟動(dòng)，biblog補(bǔ)全也可以使主庫(kù)一致
3.innodb_flush_log_at_trx_commit=1 修改參數(shù)為1
4.mysql半同步（semi sync）
七、使用mysqldump方式構(gòu)建主從，添加了--set-gtid-purged=off 導(dǎo)致主從構(gòu)建失敗？？
備份不會(huì)有set-gtid-purged=
八、基于binlog+gtid方式截取日志無(wú)法正?；謴?fù)，是什么原因?qū)е隆?/h3>
gtid冪等性，恢復(fù)時(shí)要加上--skip-gtid參數(shù)
九、ibdata1共享表空間損壞，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法啟動(dòng)，備份也失效，解決思路。
利用表空間遷移，將業(yè)務(wù)庫(kù)的.ibd結(jié)尾的文件，導(dǎo)出，然后再新的數(shù)據(jù)庫(kù)，創(chuàng)建表結(jié)構(gòu)一樣的數(shù)據(jù)庫(kù)，導(dǎo)入表空間。
使用mysqlfrm工具可以知道元數(shù)據(jù)庫(kù)的表結(jié)構(gòu)
十、一條SQL語(yǔ)句，昨天執(zhí)行很快，突然變慢是什么原因？
索引失效，統(tǒng)計(jì)數(shù)據(jù)不真實(shí)、
十一、在做DDL操作時(shí)，數(shù)據(jù)庫(kù)hang住，什么原因？
出現(xiàn)了MDL元數(shù)據(jù)鎖的問(wèn)題
十二、http409錯(cuò)誤，達(dá)到連接上線(xiàn)，是什么原因?qū)е拢?/h3>
連接數(shù)上線(xiàn)，mysql連接數(shù)默認(rèn)214個(gè)、
十三、連接數(shù)設(shè)置不生效，最多214，是什么原因
需要?jiǎng)?chuàng)建文件/etc/systemd/system/mariadb.service.d/limits.conf
來(lái)修改連接數(shù)：
vi limits.conf
[Service]
LimitNOFILE=10000
十四、數(shù)據(jù)庫(kù)連接不上，可能的原因，如何排查。
網(wǎng)絡(luò)，用戶(hù)不對(duì)，端口不對(duì)，防火墻阻止，連接數(shù)上限，看錯(cuò)誤日志。
十五、數(shù)據(jù)庫(kù)升級(jí)時(shí)遇到過(guò)什么故障？
5.5版本升級(jí)到5.7，要先升級(jí)到5.6再升級(jí)到5.7
十六、安裝部署數(shù)據(jù)庫(kù)遇到什么故障？
版本不兼容
配置文件不對(duì)
目錄沒(méi)創(chuàng)建
權(quán)限沒(méi)改
初始化不成功
非技術(shù)
一、上家公司用的什么架構(gòu)？數(shù)據(jù)量多大？QPS/TPS多少？
高可用+讀寫(xiě)分離
高可用+分布式
數(shù)據(jù)量在TB以上，
QPS 20000-50000不等
TPS 800-1500
二、在公司都干什么活？？
1.日常巡檢
2.備份數(shù)據(jù)
3.配合開(kāi)發(fā)，代碼審計(jì)，審核，改寫(xiě)，設(shè)計(jì)
4.監(jiān)控和優(yōu)化
5.架構(gòu)選型。調(diào)研，測(cè)試
6.應(yīng)急處理
三、DBA需要掌握哪些知識(shí)？？
1.熟練操作各種sql語(yǔ)句
2.熟悉數(shù)據(jù)庫(kù)中權(quán)限和用戶(hù)的管理，具備一定安全知識(shí)
3.具備數(shù)據(jù)庫(kù)恢復(fù)，備份技巧。
4.對(duì)數(shù)據(jù)庫(kù)操作系統(tǒng)所在的操作系統(tǒng)有一定的認(rèn)識(shí)和管理能，因?yàn)閿?shù)據(jù)庫(kù)系統(tǒng)是不能脫離操作系統(tǒng)獨(dú)立運(yùn)行。
四、喜歡MySQL嗎，平常學(xué)習(xí)渠道有哪些？
熱衷
一般會(huì)參加一些數(shù)據(jù)庫(kù)大會(huì)，論壇，網(wǎng)上的論壇博客。
看一些技術(shù)類(lèi)的書(shū)
五、最擅長(zhǎng)的MySQL哪部分？
1.架構(gòu)設(shè)計(jì)
2.優(yōu)化，
3.處理一些常見(jiàn)的問(wèn)題
4.底層原理
5.備份恢復(fù)
6.索引創(chuàng)建
7.分庫(kù)分表
六、DBA應(yīng)該具備哪些職業(yè)素養(yǎng)？
人品，嚴(yán)謹(jǐn)，細(xì)心。善于底層學(xué)習(xí)，善于分享，承擔(dān)壓力，知識(shí)面廣，差異化發(fā)展。
優(yōu)化類(lèi)
一、公司如何監(jiān)控mysql的？都監(jiān)控哪些項(xiàng)目？
zabbix,
監(jiān)控內(nèi)存、事務(wù)、線(xiàn)程、QPS、TPS、鎖、等待、參數(shù)的評(píng)估指標(biāo)
二、PT工具都有哪些？
pt-osc
pt-archiver
pt-query-digest
pt-主從
pt-kill
三、索引優(yōu)化的規(guī)范是什么？如何建索引？哪些情況不走索引？
建索引的原則：
1.必須要有主鍵，如果沒(méi)有可以做為主鍵條件的列，創(chuàng)建無(wú)關(guān)列
2.經(jīng)常做為where條件列， order by group by join on distinct的條件（業(yè)務(wù)：產(chǎn)品能力+用戶(hù)行為）
3.最好使用唯一值多的作為索引，如果索引列重復(fù)值較多，可以考慮使用聯(lián)合索引
4.列值長(zhǎng)度較長(zhǎng)的索引列。建議使用前綴索引
5.降低索引條目，一方面不要?jiǎng)?chuàng)建沒(méi)用索引，不常用的索引清理，pwecona toolkit (xxxxx)
6.索引維護(hù)要避開(kāi)業(yè)務(wù)繁忙期
不走索引的情況：
1.沒(méi)有查詢(xún)條件，或者查詢(xún)條件沒(méi)有建立索引
2.查詢(xún)結(jié)果集是原表中的大部分?jǐn)?shù)據(jù)，應(yīng)該是15-25%以上
3.索引本身失效。統(tǒng)計(jì)數(shù)據(jù)不真實(shí)
4.查詢(xún)條件使用函數(shù)在索引列上，或者對(duì)索引列進(jìn)行運(yùn)算，運(yùn)算包括（+。-。*。/。！=）
5.隱式轉(zhuǎn)換導(dǎo)致索引失效，這一點(diǎn)應(yīng)重視，也是開(kāi)發(fā)經(jīng)常犯的錯(cuò)
6.<>,not in 不走索引
7.like "%-"百分號(hào)在前面的不走
四、如何定位SQL語(yǔ)句問(wèn)題，如何進(jìn)行優(yōu)化？
1.show processlist;獲取緩慢的SQL.
2.explain 查看執(zhí)行計(jì)劃，全表掃描，鎖等待，索引方面
3.對(duì)SQL語(yǔ)句進(jìn)行調(diào)優(yōu)，有鎖等待的調(diào)整順序，索引不正確的修改語(yǔ)句，沒(méi)索引的創(chuàng)建索引
4.測(cè)試庫(kù)測(cè)試，總結(jié)結(jié)果，交給開(kāi)發(fā)測(cè)試。
5.對(duì)在測(cè)試中沒(méi)有問(wèn)題的SQL語(yǔ)句，結(jié)合zabbix監(jiān)控記錄及對(duì)硬件CPU進(jìn)行分析，硬件是否達(dá)到瓶頸需要升級(jí)
五、平時(shí)調(diào)整過(guò)什么參數(shù)？每個(gè)參數(shù)調(diào)整依據(jù)是什么？
Mylsam存儲(chǔ)引擎內(nèi)存優(yōu)化：
key_buffer_size: 決定Mylsam索引緩沖區(qū)的大小，影響了Mylsam表的存取書(shū)讀。
read_buffer_size 經(jīng)常順序掃描的Mylsam表，調(diào)整這個(gè)參數(shù)可以改善性能。
read_md_buffer_size 需要做排序的Mylsam表查詢(xún)，增加參數(shù)的值，可改善sql性能，設(shè)置的太大會(huì)內(nèi)存浪費(fèi)
innodb存儲(chǔ)引擎內(nèi)存優(yōu)化：
innodb_buffer_pool_size: 此參數(shù)決定了innodb存儲(chǔ)引擎表數(shù)據(jù)和索引數(shù)量的最大緩沖大小 ，物理內(nèi)存的80%
innodb_log_buffer_size:此參數(shù)決定了重做日志的緩沖大小，針對(duì)可能產(chǎn)生的大量更新記錄的大事務(wù)，一般調(diào)整到64M
innodb_lock_wait_timeout:此參數(shù)決定了行鎖等待的時(shí)間，一般調(diào)整為10秒。
連接層優(yōu)化參數(shù)：
max_connections=1000: 最大連接數(shù)的優(yōu)化
wait_timeout=600 :控制連接最大空閑時(shí)長(zhǎng)參數(shù)
max_allowed_packet=32M 允許插入一天數(shù)據(jù)的大小。
雙一參數(shù)優(yōu)化：
innodb_flush_log_at_trx_commit=1 每次事務(wù)提交，內(nèi)存中的數(shù)據(jù)立即刷寫(xiě)到磁盤(pán)。
sync_binlog=1:保證數(shù)據(jù)安全的機(jī)制。
刷寫(xiě)策略?xún)?yōu)化：
innodb_io_capacity=1000 ：刷寫(xiě)賬頁(yè)的速度
六、如何監(jiān)控鎖的狀態(tài)？
1.查看鎖等待。
show status like 'innodb_row_lock';
2.查看當(dāng)前運(yùn)行所有事務(wù)
select * from information_schema.innodb_trx;
3.查看等待鎖和鎖源
select * from sys.innodb_lock_waies;
---->block_pid
4.通過(guò)鎖源的pid找到執(zhí)行SQL的thread_id
select * from performance_schema.thread_id where processlist=進(jìn)程號(hào)
5.通過(guò)thread_id找到具體的所言語(yǔ)句
select * from performance_schema.events_statements_current where thread_id=id號(hào)
select * from performance_schema.events_statements_history where thread_id=id號(hào)
七、數(shù)據(jù)庫(kù)CPU爆滿(mǎn)，排查思路？
1.通過(guò)top -Hp 詳細(xì)排查線(xiàn)程
2.排查sys wait,us是否正常
3.show processlist;查看導(dǎo)致數(shù)據(jù)慢的sql語(yǔ)句
4.查看是不是有鎖等待，索引的問(wèn)題
八、你對(duì)mysql做過(guò)哪些優(yōu)化
操作系統(tǒng)上：存儲(chǔ):網(wǎng)絡(luò)：OS，
實(shí)例：參數(shù)優(yōu)化
應(yīng)用上：SQL語(yǔ)句的優(yōu)化，索引、鎖的優(yōu)化
架構(gòu)：搭建高可用、讀寫(xiě)分離、分布式架構(gòu)
架構(gòu)類(lèi)
一、Percona-XtraDB-Cluster高可用集群的工作原理
PXC最常使用以下4個(gè)端口號(hào)：
3306-數(shù)據(jù)庫(kù)對(duì)外服務(wù)的端口號(hào)。
4444-請(qǐng)求SST的端口（SST是指數(shù)據(jù)庫(kù)一個(gè)備份全量文件的傳輸。）
4567-組成員之間進(jìn)行溝通的一個(gè)端口號(hào)
4568-用于傳輸IST（相對(duì)于SST來(lái)說(shuō)的一個(gè)增量）
PXC的工作流程：
1.首先客戶(hù)端先發(fā)起一個(gè)事務(wù)，該事務(wù)先在本地執(zhí)行，執(zhí)行完成之后就要發(fā)起對(duì)事務(wù)的提交操作了。
2.在提交之前需要將產(chǎn)生的復(fù)制寫(xiě)集廣播出去，然后獲取到一個(gè)全局的事務(wù)ID號(hào)，一并傳送到另一個(gè)節(jié)點(diǎn)上面。通過(guò)合并數(shù)據(jù)之后，發(fā)現(xiàn)沒(méi)有沖突數(shù)據(jù)，執(zhí)行apply_cd和commit_cb動(dòng)作，否則就需要取消此次事務(wù)的操作。
3.而當(dāng)前server節(jié)點(diǎn)通過(guò)驗(yàn)證之后，執(zhí)行提交操作，并返回OK，如果驗(yàn)證沒(méi)通過(guò)，則執(zhí)行回滾。
4.當(dāng)然在生產(chǎn)中至少要有3個(gè)節(jié)點(diǎn)的集群環(huán)境，如果其中一個(gè)節(jié)點(diǎn)沒(méi)有驗(yàn)證通過(guò)，出現(xiàn)了數(shù)據(jù)沖突，那么此時(shí)采取的方式就是講出現(xiàn)不一致的節(jié)點(diǎn)踢出集群環(huán)境，而且它自己會(huì)執(zhí)行shutdown命令，自動(dòng)關(guān)機(jī)。
二、mycat分布式架構(gòu)，如何設(shè)計(jì)的？
三、在維護(hù)公司MHA架構(gòu)時(shí)主要做哪些工作？
1.定期的切換
2.故障監(jiān)控處理
3.主從優(yōu)化，降低延時(shí)
四、MHA高可用架構(gòu)Failover(故障轉(zhuǎn)移)原理
1.masterha_manager啟動(dòng)manager程序,讀取app1.cnf文件，獲取節(jié)點(diǎn)信息
2.調(diào)用masterha_master_monitor腳本，通過(guò)MHA用戶(hù)連接各個(gè)節(jié)點(diǎn)探測(cè)心跳
3.每?jī)擅胩綔y(cè)主庫(kù)心跳一次，探測(cè)到心跳，斷開(kāi)，一共給四次連接機(jī)會(huì)
4.四次連接不通，進(jìn)入選主流程
a.生成一下屬主，存儲(chǔ)從庫(kù)節(jié)點(diǎn)號(hào)碼
b.進(jìn)行判斷
5.選擇完新主，進(jìn)入數(shù)據(jù)補(bǔ)償間斷
a.主庫(kù)ssh能連接：將確實(shí)部分的binlog截取，存放在各個(gè)從庫(kù)，進(jìn)行補(bǔ)償
b.ssh不能連接：計(jì)算從庫(kù)的差異，互相補(bǔ)償
6.主從切換，接觸所有主從關(guān)系，構(gòu)建新的主從關(guān)系
7.調(diào)用master_ip_failover進(jìn)行vip切換，
8.調(diào)用masterha_conf_host將故障節(jié)點(diǎn)踢出集群（刪除配置文件信息）
9.manager自殺，程序退出
10調(diào)用aend_report發(fā)送告警郵件
四、MHA重要腳本的作用
Manager工具包主要包括以下幾個(gè)工具：
masterha_manger 啟動(dòng)MHA
masterha_check_ssh 檢查MHA的SSH配置狀況
masterha_check_repl 檢查MySQL復(fù)制狀況
masterha_master_monitor 檢測(cè)master是否宕機(jī)
masterha_check_status 檢測(cè)當(dāng)前MHA運(yùn)行狀態(tài)
masterha_master_switch 控制故障轉(zhuǎn)移（自動(dòng)或者手動(dòng)）
masterha_conf_host 添加或刪除配置的server信息
Node工具包主要包括以下幾個(gè)工具：
這些工具通常由MHA Manager的腳本觸發(fā)，無(wú)需人為操作
save_binary_logs 保存和復(fù)制master的二進(jìn)制日志
apply_diff_relay_logs 識(shí)別差異的中繼日志事件并將其差異的事件應(yīng)用于其他的
purge_relay_logs 清除中繼日志（不會(huì)阻塞SQL線(xiàn)程）
五、MHA的搭建過(guò)程
1.搭建1主2從，獨(dú)立節(jié)點(diǎn)、GTID
2.配置各節(jié)點(diǎn)互信無(wú)密碼認(rèn)證
3.配置所有節(jié)點(diǎn)軟連接
4.在主庫(kù)建用戶(hù)
5.軟件安裝（perl\mananger\node）
6.狀態(tài)檢查
a.互信檢查
b.主從狀態(tài)檢查
7.啟動(dòng)MHA
8.vip\binlogserver\sendreport
六、介紹你熟悉的高可用解決方案
搭建MHA架構(gòu) manager node
監(jiān)控
自動(dòng)選主
數(shù)據(jù)補(bǔ)償
應(yīng)用透明
故障通知
七、請(qǐng)介紹一下你們公司的數(shù)據(jù)庫(kù)架構(gòu)？
高可用架構(gòu)：MHA、PXC、MGC、MGR
讀寫(xiě)分離：ProxySQL、Maxscale、mysql-router、mycat
分布式架構(gòu)：mycat/sharding-jdbc
主從復(fù)制類(lèi)
一、如何為運(yùn)行了兩年的數(shù)據(jù)庫(kù)，構(gòu)建一個(gè)從庫(kù)。請(qǐng)說(shuō)明步驟，是否要停主庫(kù)？
不需要停主庫(kù)
1.主庫(kù)開(kāi)binlog,建立復(fù)制用戶(hù)，給replication slave權(quán)限
2.每個(gè)節(jié)點(diǎn)的server_id和server_uuid不同
3.初始化從庫(kù)數(shù)據(jù)
4.備份主庫(kù)數(shù)據(jù)，恢復(fù)到從庫(kù)
5.建立主從連接，change master to | start salve
二、簡(jiǎn)述主從復(fù)制原理？
1.線(xiàn)程：建立連接時(shí)和從庫(kù)進(jìn)行交互線(xiàn)程。監(jiān)控binlog狀態(tài)，傳輸binlog給從庫(kù)。
2.文件：從庫(kù)啟動(dòng)IO線(xiàn)程，接收到binlog文件寫(xiě)入到relaylog文件中，然后創(chuàng)建一個(gè)sql線(xiàn)程讀取relaylog內(nèi)容.
3.master_info會(huì)以文件或表的形式存儲(chǔ)主庫(kù)連接信息+binlog位置點(diǎn)。relaylog_info也會(huì)以文件或表的形式存儲(chǔ)從庫(kù)的位置點(diǎn)。
4.過(guò)程：
a.從庫(kù)執(zhí)行change master to ,相關(guān)信息存儲(chǔ)到master_info, 執(zhí)行start slave，啟動(dòng)IO和SQL線(xiàn)程
b.IO線(xiàn)程獲取master_info信息，請(qǐng)求鏈接主庫(kù)，主庫(kù)接收請(qǐng)求，創(chuàng)建dump線(xiàn)程監(jiān)控binlog變化，傳輸binlog給從庫(kù)IO.
c.主庫(kù)的dump線(xiàn)程根據(jù)IO線(xiàn)程提供的binlog位置點(diǎn)，截取部分日志傳給從庫(kù)IO
d.從庫(kù)IO接收到dump日志，存儲(chǔ)到relaylog中，并且將binlog為位置點(diǎn)更新到mastser_info中
e.SQL線(xiàn)程根據(jù)relaylog_info。回放最新的relaylog，并更新。一直重復(fù)以上操作。
f.relaylog用完之后會(huì)定期處理
三、如何監(jiān)控主從復(fù)制，說(shuō)明監(jiān)控要點(diǎn)？
主庫(kù)方面：
1.通過(guò)主庫(kù)線(xiàn)程 show processlist;可以查看到從庫(kù)線(xiàn)程信息
2.通過(guò) show slave hosts;可以查看到從庫(kù)的ID信息
3.重點(diǎn)監(jiān)控 show slave status\G
a.故障監(jiān)控：
b.主從延時(shí)：
四、簡(jiǎn)述遇到過(guò)的主從復(fù)制故障？如何監(jiān)控、分析、規(guī)避、處理
1.連接主庫(kù): connecting
#可能原因
連接信息有誤。
網(wǎng)絡(luò)故障。
防火墻。
最大連接數(shù)上線(xiàn)。
# 排查方法：
[root@db01 data]# mysql -urepl -p123 -h10.0.0.51 -P 3307
# 處理方法：
mysql -S /data/3308/mysql.sock -e "stop slave;reset slave all;"
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=674,
MASTER_CONNECT_RETRY=10;
start slave
2 請(qǐng)求日志: NO
主庫(kù)日志損壞。
日志起點(diǎn)寫(xiě)錯(cuò)。
server_id重復(fù)
# 排查方法
show slave status \G
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 674
Last_IO_Error: xxxx
SQL 線(xiàn)程故障： 回放中繼日志
中繼日志損壞
1. 從庫(kù) 停SQL線(xiàn)程
stop slave sql_thread ;
2. 主庫(kù)發(fā)生新的操作
create database test1;
3. 從庫(kù)刪除relaylog
rm -rf /data/3308/data/db01-relay-bin.00000*
4. 啟動(dòng)SQL線(xiàn)程
start slave sql_thread ;
修復(fù)：
1. cat /data/3308/data/relay-log.info ----> binlog 位置點(diǎn)
2. 重構(gòu)
stop slave ;
reset slave all;
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
日志回放失敗（執(zhí)行不了SQL）
# 1. 修改的對(duì)象不存在
# 2. 創(chuàng)建的對(duì)象已存在
# 3. 約束沖突
# 4. 主從配置不同
# 5. SQL_MODE不兼容
# 6. 主從版本差異
方法0：
從庫(kù)逆反操作。
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
#將同步指針向下移動(dòng)一個(gè)，如果多次不同步，可以重復(fù)操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常見(jiàn)錯(cuò)誤代碼:
1007:對(duì)象已存在
1032:無(wú)法執(zhí)行DML
1062:主鍵沖突,或約束沖突
但是，以上操作有時(shí)是有風(fēng)險(xiǎn)的，最安全的做法就是重新構(gòu)建主從。把握一個(gè)原則,一切以主庫(kù)為主.
方法三： PT工具
pt-table-checksum
pt-table-sync
方法四：從庫(kù)只讀
mysql> select @@read_only;
mysql> select @@super_read_only;
五、簡(jiǎn)述哪些情況會(huì)導(dǎo)致主從延時(shí)？如何監(jiān)控，分析，規(guī)避，處理
導(dǎo)致主從延時(shí)：
1.主庫(kù)binlog日志文件落地不及時(shí)，
2.主庫(kù)沒(méi)有GTID，主庫(kù)并發(fā)多個(gè)事務(wù)，大事務(wù)，并發(fā)事務(wù)量大，
3.單一sql線(xiàn)程，只能串行relaylog。主庫(kù)并發(fā)事務(wù)，只能是串行的。如果，大事務(wù)，并發(fā)量大，都會(huì)導(dǎo)致較高回放延時(shí)。
4.網(wǎng)絡(luò)慢，主從配置相差大
5.6版本加入了GTID功能，在傳輸時(shí)就可以并行傳輸日志了，并且GTID模式下，可以開(kāi)啟多個(gè) SQL進(jìn)程。但SQL回放時(shí)只針對(duì)不同庫(kù)并行串行
5.7版本即使不開(kāi)GTID，會(huì)自動(dòng)生成，GTID模式下，真正實(shí)現(xiàn)了并行回放
六、介紹你了解的主從復(fù)制模型？
1. 一主多從，一主一從
2.雙主
3.級(jí)聯(lián)復(fù)制 主庫(kù)復(fù)制給從庫(kù)，從庫(kù)再?gòu)?fù)制給其他從庫(kù)
4.延時(shí)從庫(kù) 人為配置從庫(kù)和這句庫(kù)延時(shí)一段時(shí)間，用來(lái)處理邏輯卷?yè)p壞
5.過(guò)濾復(fù)制 只復(fù)制部分?jǐn)?shù)據(jù)
設(shè)置白名單和黑名單，
6.半同步
七 傳統(tǒng)主從復(fù)制是異步還是同步？會(huì)不會(huì)出現(xiàn)主從不一致？出現(xiàn)有什么好的方法解決和預(yù)防？
傳統(tǒng)主從復(fù)制是異步，有可能出現(xiàn)主從不一致，使用PT工具解決。
八、延時(shí)從庫(kù)的實(shí)現(xiàn)原理？主要解決什么問(wèn)題？？如何使用延時(shí)從庫(kù)？？
實(shí)現(xiàn)：
SQL線(xiàn)程延時(shí):數(shù)據(jù)已經(jīng)寫(xiě)入relaylog中了,SQL線(xiàn)程"慢點(diǎn)"運(yùn)行
一般企業(yè)建議3-6小時(shí),具體看公司運(yùn)維人員對(duì)于故障的反應(yīng)時(shí)間
主要解決邏輯損壞：
邏輯故障的恢復(fù)思路
1.及時(shí)發(fā)現(xiàn)主庫(kù)發(fā)生了邏輯損壞
2.立即停止延時(shí)從庫(kù)的SQL線(xiàn)程
3.掛維護(hù)頁(yè)
4.截取relay進(jìn)行恢復(fù)(人為模擬SQL線(xiàn)程工作，直到drop之前)
起點(diǎn)：stop sql線(xiàn)程時(shí)的relaylog位置點(diǎn)
終點(diǎn)：drop 之前的位置點(diǎn)
5.截取的日志恢復(fù)到從庫(kù)
6.從庫(kù)替代主庫(kù)工作
九、過(guò)濾復(fù)制實(shí)現(xiàn)原理？你們公司過(guò)濾復(fù)制架構(gòu)如何設(shè)計(jì)的？
replicate_do_db=庫(kù) 白名單
replicate_ignore_db=庫(kù) 黑名單
只需要在配置文件設(shè)置想要和不想要復(fù)制的庫(kù)或表的黑白名單就可以實(shí)現(xiàn)過(guò)濾復(fù)制了。
公司一般會(huì)排除系統(tǒng)庫(kù)不復(fù)制會(huì)設(shè)置，用來(lái)復(fù)制較為重要的業(yè)務(wù)庫(kù)
十、增強(qiáng)半同步復(fù)制實(shí)現(xiàn)原理，5.6和5.7版本有什么區(qū)別？
原理：
1.主庫(kù)執(zhí)行新的事物，commit時(shí)，更新show master status\G,觸發(fā)一個(gè)信號(hào)binlog
2.binlog 線(xiàn)程接收到主庫(kù)的show master status\G信息，通知從庫(kù)日志更新了
3.從庫(kù)IO線(xiàn)程請(qǐng)求新的二進(jìn)制日志事件，
4.主庫(kù)會(huì)通過(guò)dump線(xiàn)程傳送新的日志事件，給從庫(kù)IO線(xiàn)程
5.從庫(kù)IO線(xiàn)程接收到binlog日志，當(dāng)日志寫(xiě)入到磁盤(pán)上的relaylog文件時(shí)，給主庫(kù)ACK_receiver線(xiàn)程
6.ACK_receiver線(xiàn)程觸發(fā)一個(gè)事件，告訴主庫(kù)commit可以成功了。
7.如果ACK達(dá)到了我們預(yù)設(shè)值的超時(shí)時(shí)間，半同步復(fù)制會(huì)切換為原始的異步復(fù)制。
區(qū)別：
5.6版本加入了GC機(jī)制，半同步復(fù)制開(kāi)始接受，使用after_commit機(jī)制，但是是在redo_commit之后今次那個(gè)等待ACK確認(rèn)
如果主庫(kù)redo commit間斷宕機(jī)，從庫(kù)又獲取到了binlog,會(huì)出現(xiàn)從庫(kù)比主庫(kù)數(shù)據(jù)對(duì)的問(wèn)題，導(dǎo)致數(shù)據(jù)不一致。
5.7版本以后，加入了after_sync機(jī)制，在binlog commit間斷，等待從庫(kù)ACK，不管誰(shuí)宕機(jī)，都能保證最終一致性
十一、簡(jiǎn)述MySQL Group Replication（復(fù)制組）工作原理？Paxos 分布式一致性協(xié)議工作原理？
復(fù)制組：
由多個(gè)節(jié)點(diǎn)共同組成一個(gè)復(fù)制組，一個(gè)事務(wù)提交，必須經(jīng)過(guò)組內(nèi)大多數(shù)節(jié)點(diǎn)（N/2 + 1）協(xié)議并通過(guò)，才能提交。
分布式一致性協(xié)議：
用來(lái)解決分布式中一致性問(wèn)題，分布一致性算法，最基本的功能是為了在多個(gè)進(jìn)程之間對(duì)某個(gè)值達(dá)成一致。確定一個(gè)值，一旦被寫(xiě)入就不可改變，解決多節(jié)點(diǎn)寫(xiě)入問(wèn)題。
備份恢復(fù)篇
一、在備份這塊都做過(guò)什么具體工作？
1.備份策略
2.備份檢查
3.恢復(fù)演練
4.故障快速恢復(fù)
5.遷移數(shù)據(jù)庫(kù)
二、你們公司備份策略是什么樣子的？
1.工具使用：
邏輯備份：mysqldump（MDP）
物理備份：percona Xtrabackup(PXB)
2.備份周期和方式
100G以?xún)?nèi)，每天邏輯備份全備，兩份完整備份，日志每天都備。
100G以上，使用物理備份，每周全備，其他時(shí)間做增量和日志備份
3.類(lèi)型
熱備：數(shù)據(jù)庫(kù)正常業(yè)務(wù)時(shí)備份
溫備：鎖表備份，只能查詢(xún)不能修改
冷備：關(guān)閉業(yè)務(wù)，數(shù)據(jù)庫(kù)沒(méi)有變更情況下備份
三、你們公司用什么工具備份
mysqldump (MDP)
percona Xtarbackup (XBK)
mydumper
主從
延時(shí)從庫(kù)
四、請(qǐng)介紹msyqldump核心參數(shù)，--master-data --single-transaction功能
--master-data=2
1.自動(dòng)鎖表（非innodb），global read lock
2.記錄binlog位置
--single-transaction
對(duì)innodb表開(kāi)啟快照備份
三mysqldump原理
1.提取innodb數(shù)據(jù)快照，轉(zhuǎn)換為SQL，存儲(chǔ)到sql文件中
2.非innodb表，全局鎖表，轉(zhuǎn)換為sql，轉(zhuǎn)存到sql文件
3.備份方式 create db create table insert
mysqldump的大致實(shí)現(xiàn)過(guò)程是：連接 -> 初始化信息 -> 刷新表（鎖表）-> 記錄偏移量 -> 開(kāi)啟事務(wù)（一致性快照）-> 記錄偏移量 -> 解鎖表，因?yàn)殚_(kāi)啟了一致性讀，可以得到innodb的一致性，又因?yàn)榻怄i表了，MyISAM表一致性得不到保證，所以盡量別使用MyISAM表。
四、請(qǐng)介紹xtarbackup工具備份原理
1.innobackupex在啟動(dòng)后又，會(huì)分出一個(gè)進(jìn)程，啟動(dòng)xtrabackup進(jìn)程，然后等待XBK備份完ibd文件。
2.XBK在備份innodb相關(guān)數(shù)據(jù)時(shí)，是有兩種線(xiàn)程的，1個(gè)是redo拷貝線(xiàn)程，一個(gè)是idb拷貝線(xiàn)程負(fù)責(zé)拷貝IBD文件。redo拷貝線(xiàn)程只有一個(gè)，在ibd拷貝線(xiàn)程之前啟動(dòng)，在idb線(xiàn)程結(jié)束后結(jié)束。XBK開(kāi)始執(zhí)行，先啟動(dòng)redo線(xiàn)程，從最新的checkpoint點(diǎn)開(kāi)始順序拷貝。然后再啟動(dòng)ibd數(shù)據(jù)拷貝線(xiàn)程，在拷貝idb過(guò)程中，innobackupex進(jìn)程一致處于等待狀態(tài)。（等待文件被創(chuàng)建）
3.XBK拷貝完成idb文件后,通知innobackupex，同時(shí)自己進(jìn)入等待（redo線(xiàn)程任然繼續(xù)拷貝）
4. innobackupex 收到XBK 通知后，執(zhí)行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位點(diǎn)，然后開(kāi)始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷貝非 InnoDB 文件過(guò)程中，因?yàn)閿?shù)據(jù)庫(kù)處于全局只讀狀態(tài)，如果在業(yè)務(wù)的主庫(kù)備份的話(huà)，要特別小心，非 InnoDB 表（主要是MyISAM）比較多的話(huà)整庫(kù)只讀時(shí)間就會(huì)比較長(zhǎng)，這個(gè)影響一定要評(píng)估到。
5. 當(dāng) innobackupex 拷貝完所有非 InnoDB 表文件后，通知 XBK（通過(guò)刪文件） ，同時(shí)自己進(jìn)入等待（等待另一個(gè)文件被創(chuàng)建）；
6. XBK收到 innobackupex 備份完非 InnoDB 通知后，就停止 redo 拷貝線(xiàn)程，然后通知 innobackupex redo log 拷貝完成（通過(guò)創(chuàng)建文件）；
7. innobackupex 收到 redo 備份完成通知后，就開(kāi)始解鎖，執(zhí)行 UNLOCK TABLES；
8. 最后 innobackupex 和 XBK進(jìn)程各自完成收尾工作，如資源的釋放、寫(xiě)備份元數(shù)據(jù)信息等，innobackupex 等待 XBK 子進(jìn)程結(jié)束后退出。
五 增量備份
XBK 是支持增量備份的，但是只能對(duì) InnoDB 做增量，InnoDB 每個(gè) page 有個(gè) LSN 號(hào)，LSN 是全局遞增的，page 被更改時(shí)會(huì)記錄當(dāng)前的 LSN 號(hào)，page中的 LSN 越大，說(shuō)明當(dāng)前page越新（最近被更新）。每次備份會(huì)記錄當(dāng)前備份到的LSN（xtrabackup_checkpoints 文件中），增量備份就是只拷貝LSN大于上次備份的page，比上次備份小的跳過(guò)，每個(gè) ibd 文件最終備份出來(lái)的是增量 delta 文件。
MyISAM 是沒(méi)有增量的機(jī)制的，每次增量備份都是全部拷貝的。
增量備份過(guò)程和全量備份一樣，只是在 ibd 文件拷貝上有不同。
六、恢復(fù)過(guò)程
如果看恢復(fù)備份集的日志，會(huì)發(fā)現(xiàn)和 mysqld 啟動(dòng)時(shí)非常相似，其實(shí)備份集的恢復(fù)就是類(lèi)似 mysqld crash后，做一次 crash recover。
恢復(fù)的目的是把備份集中的數(shù)據(jù)恢復(fù)到一個(gè)一致性位點(diǎn)，所謂一致就是指原數(shù)據(jù)庫(kù)某一時(shí)間點(diǎn)各引擎數(shù)據(jù)的狀態(tài)，比如 MyISAM 中的數(shù)據(jù)對(duì)應(yīng)的是 15:00 時(shí)間點(diǎn)的，InnoDB 中的數(shù)據(jù)對(duì)應(yīng)的是 15:20 的，這種狀態(tài)的數(shù)據(jù)就是不一致的。PXB 備份集對(duì)應(yīng)的一致點(diǎn)，就是備份時(shí)FTWRL的時(shí)間點(diǎn)，恢復(fù)出來(lái)的數(shù)據(jù)，就對(duì)應(yīng)原數(shù)據(jù)庫(kù)FTWRL時(shí)的狀態(tài)。
因?yàn)閭浞輹r(shí) FTWRL 后，數(shù)據(jù)庫(kù)是處于只讀的，非 InnoDB 數(shù)據(jù)是在持有全局讀鎖情況下拷貝的，所以非 InnoDB 數(shù)據(jù)本身就對(duì)應(yīng) FTWRL 時(shí)間點(diǎn)；InnoDB 的 ibd 文件拷貝是在 FTWRL 前做的，拷貝出來(lái)的不同 ibd 文件最后更新時(shí)間點(diǎn)是不一樣的，這種狀態(tài)的 ibd 文件是不能直接用的，但是 redo log 是從備份開(kāi)始一直持續(xù)拷貝的，最后的 redo 日志點(diǎn)是在持有 FTWRL 后取得的，所以最終通過(guò) redo 應(yīng)用后的 ibd 數(shù)據(jù)時(shí)間點(diǎn)也是和 FTWRL 一致的。
所以恢復(fù)過(guò)程只涉及 InnoDB 文件的恢復(fù)，非 InnoDB 數(shù)據(jù)是不動(dòng)的。備份恢復(fù)完成后，就可以把數(shù)據(jù)文件拷貝到對(duì)應(yīng)的目錄，然后通過(guò)mysqld來(lái)啟動(dòng)了。
七、同時(shí)晚上23：00開(kāi)始備份，23:30分結(jié)束。Mdp和xbk兩個(gè)工具理論上能將數(shù)據(jù)恢復(fù)至幾點(diǎn)？
MDP :23.00
XBK:23.30
八、XBK的增量備份時(shí)如何實(shí)現(xiàn)的？
基于上一次備份LSN號(hào)變化過(guò)的數(shù)據(jù)頁(yè)進(jìn)行備份，災(zāi)備份同時(shí)產(chǎn)生的新的變更，會(huì)將redo備份、
第一次增量是依賴(lài)于全備的，將來(lái)恢復(fù)也要合并到全備中，在進(jìn)行統(tǒng)一恢復(fù)
九、Xtrabackup增量備份恢復(fù)要注意什么？
1.增量備份僅能應(yīng)用于InnoDB或XtraDB表，對(duì)于MyISAM表而言，執(zhí)行增量備份時(shí)其實(shí)進(jìn)行的是完全備份。
2.增量備份需要使用參數(shù)–incremental指定需要備份到哪個(gè)目錄，使用incremental-dir指定全備目錄；
3.進(jìn)行數(shù)據(jù)備份時(shí)，需要使用參數(shù)–apply-log redo-only先合并全備數(shù)據(jù)目錄數(shù)據(jù)，確保全備數(shù)據(jù)目錄數(shù)據(jù)的一致性；
4.再將增量備份數(shù)據(jù)使用參數(shù)–incremental-dir合并到全備數(shù)據(jù)當(dāng)中；
5.最后通過(guò)最后的全備數(shù)據(jù)進(jìn)行恢復(fù)數(shù)據(jù)，注意，如果有多個(gè)增量備份，需要逐一合并到全備數(shù)據(jù)當(dāng)中，再進(jìn)行恢復(fù)。
十、Mysqldump和xtrabackup 備份如何實(shí)現(xiàn)基于時(shí)間點(diǎn)的恢復(fù)？
MDP的--master-data=2參數(shù),自動(dòng)記錄了位置點(diǎn)信息，結(jié)合binlog恢復(fù)。
XBK的xtrabackup_binlog_info文件中記錄了binlog 和GTID的信息,結(jié)合binlog恢復(fù)
gtid冪等性，恢復(fù)時(shí)要加上--skip-gtid參數(shù)
利用表空間遷移，將業(yè)務(wù)庫(kù)的.ibd結(jié)尾的文件，導(dǎo)出，然后再新的數(shù)據(jù)庫(kù)，創(chuàng)建表結(jié)構(gòu)一樣的數(shù)據(jù)庫(kù)，導(dǎo)入表空間。
使用mysqlfrm工具可以知道元數(shù)據(jù)庫(kù)的表結(jié)構(gòu)
索引失效，統(tǒng)計(jì)數(shù)據(jù)不真實(shí)、
出現(xiàn)了MDL元數(shù)據(jù)鎖的問(wèn)題
連接數(shù)上線(xiàn)，mysql連接數(shù)默認(rèn)214個(gè)、
十三、連接數(shù)設(shè)置不生效，最多214，是什么原因
需要?jiǎng)?chuàng)建文件/etc/systemd/system/mariadb.service.d/limits.conf
來(lái)修改連接數(shù)：
vi limits.conf
[Service]
LimitNOFILE=10000
十四、數(shù)據(jù)庫(kù)連接不上，可能的原因，如何排查。
網(wǎng)絡(luò)，用戶(hù)不對(duì)，端口不對(duì)，防火墻阻止，連接數(shù)上限，看錯(cuò)誤日志。
十五、數(shù)據(jù)庫(kù)升級(jí)時(shí)遇到過(guò)什么故障？
5.5版本升級(jí)到5.7，要先升級(jí)到5.6再升級(jí)到5.7
十六、安裝部署數(shù)據(jù)庫(kù)遇到什么故障？
版本不兼容
配置文件不對(duì)
目錄沒(méi)創(chuàng)建
權(quán)限沒(méi)改
初始化不成功
非技術(shù)
一、上家公司用的什么架構(gòu)？數(shù)據(jù)量多大？QPS/TPS多少？
高可用+讀寫(xiě)分離
高可用+分布式
數(shù)據(jù)量在TB以上，
QPS 20000-50000不等
TPS 800-1500
二、在公司都干什么活？？
1.日常巡檢
2.備份數(shù)據(jù)
3.配合開(kāi)發(fā)，代碼審計(jì)，審核，改寫(xiě)，設(shè)計(jì)
4.監(jiān)控和優(yōu)化
5.架構(gòu)選型。調(diào)研，測(cè)試
6.應(yīng)急處理
三、DBA需要掌握哪些知識(shí)？？
1.熟練操作各種sql語(yǔ)句
2.熟悉數(shù)據(jù)庫(kù)中權(quán)限和用戶(hù)的管理，具備一定安全知識(shí)
3.具備數(shù)據(jù)庫(kù)恢復(fù)，備份技巧。
4.對(duì)數(shù)據(jù)庫(kù)操作系統(tǒng)所在的操作系統(tǒng)有一定的認(rèn)識(shí)和管理能，因?yàn)閿?shù)據(jù)庫(kù)系統(tǒng)是不能脫離操作系統(tǒng)獨(dú)立運(yùn)行。
四、喜歡MySQL嗎，平常學(xué)習(xí)渠道有哪些？
熱衷
一般會(huì)參加一些數(shù)據(jù)庫(kù)大會(huì)，論壇，網(wǎng)上的論壇博客。
看一些技術(shù)類(lèi)的書(shū)
五、最擅長(zhǎng)的MySQL哪部分？
1.架構(gòu)設(shè)計(jì)
2.優(yōu)化，
3.處理一些常見(jiàn)的問(wèn)題
4.底層原理
5.備份恢復(fù)
6.索引創(chuàng)建
7.分庫(kù)分表
六、DBA應(yīng)該具備哪些職業(yè)素養(yǎng)？
人品，嚴(yán)謹(jǐn)，細(xì)心。善于底層學(xué)習(xí)，善于分享，承擔(dān)壓力，知識(shí)面廣，差異化發(fā)展。
優(yōu)化類(lèi)
一、公司如何監(jiān)控mysql的？都監(jiān)控哪些項(xiàng)目？
zabbix,
監(jiān)控內(nèi)存、事務(wù)、線(xiàn)程、QPS、TPS、鎖、等待、參數(shù)的評(píng)估指標(biāo)
二、PT工具都有哪些？
pt-osc
pt-archiver
pt-query-digest
pt-主從
pt-kill
三、索引優(yōu)化的規(guī)范是什么？如何建索引？哪些情況不走索引？
建索引的原則：
1.必須要有主鍵，如果沒(méi)有可以做為主鍵條件的列，創(chuàng)建無(wú)關(guān)列
2.經(jīng)常做為where條件列， order by group by join on distinct的條件（業(yè)務(wù)：產(chǎn)品能力+用戶(hù)行為）
3.最好使用唯一值多的作為索引，如果索引列重復(fù)值較多，可以考慮使用聯(lián)合索引
4.列值長(zhǎng)度較長(zhǎng)的索引列。建議使用前綴索引
5.降低索引條目，一方面不要?jiǎng)?chuàng)建沒(méi)用索引，不常用的索引清理，pwecona toolkit (xxxxx)
6.索引維護(hù)要避開(kāi)業(yè)務(wù)繁忙期
不走索引的情況：
1.沒(méi)有查詢(xún)條件，或者查詢(xún)條件沒(méi)有建立索引
2.查詢(xún)結(jié)果集是原表中的大部分?jǐn)?shù)據(jù)，應(yīng)該是15-25%以上
3.索引本身失效。統(tǒng)計(jì)數(shù)據(jù)不真實(shí)
4.查詢(xún)條件使用函數(shù)在索引列上，或者對(duì)索引列進(jìn)行運(yùn)算，運(yùn)算包括（+。-。*。/。！=）
5.隱式轉(zhuǎn)換導(dǎo)致索引失效，這一點(diǎn)應(yīng)重視，也是開(kāi)發(fā)經(jīng)常犯的錯(cuò)
6.<>,not in 不走索引
7.like "%-"百分號(hào)在前面的不走
四、如何定位SQL語(yǔ)句問(wèn)題，如何進(jìn)行優(yōu)化？
1.show processlist;獲取緩慢的SQL.
2.explain 查看執(zhí)行計(jì)劃，全表掃描，鎖等待，索引方面
3.對(duì)SQL語(yǔ)句進(jìn)行調(diào)優(yōu)，有鎖等待的調(diào)整順序，索引不正確的修改語(yǔ)句，沒(méi)索引的創(chuàng)建索引
4.測(cè)試庫(kù)測(cè)試，總結(jié)結(jié)果，交給開(kāi)發(fā)測(cè)試。
5.對(duì)在測(cè)試中沒(méi)有問(wèn)題的SQL語(yǔ)句，結(jié)合zabbix監(jiān)控記錄及對(duì)硬件CPU進(jìn)行分析，硬件是否達(dá)到瓶頸需要升級(jí)
五、平時(shí)調(diào)整過(guò)什么參數(shù)？每個(gè)參數(shù)調(diào)整依據(jù)是什么？
Mylsam存儲(chǔ)引擎內(nèi)存優(yōu)化：
key_buffer_size: 決定Mylsam索引緩沖區(qū)的大小，影響了Mylsam表的存取書(shū)讀。
read_buffer_size 經(jīng)常順序掃描的Mylsam表，調(diào)整這個(gè)參數(shù)可以改善性能。
read_md_buffer_size 需要做排序的Mylsam表查詢(xún)，增加參數(shù)的值，可改善sql性能，設(shè)置的太大會(huì)內(nèi)存浪費(fèi)
innodb存儲(chǔ)引擎內(nèi)存優(yōu)化：
innodb_buffer_pool_size: 此參數(shù)決定了innodb存儲(chǔ)引擎表數(shù)據(jù)和索引數(shù)量的最大緩沖大小 ，物理內(nèi)存的80%
innodb_log_buffer_size:此參數(shù)決定了重做日志的緩沖大小，針對(duì)可能產(chǎn)生的大量更新記錄的大事務(wù)，一般調(diào)整到64M
innodb_lock_wait_timeout:此參數(shù)決定了行鎖等待的時(shí)間，一般調(diào)整為10秒。
連接層優(yōu)化參數(shù)：
max_connections=1000: 最大連接數(shù)的優(yōu)化
wait_timeout=600 :控制連接最大空閑時(shí)長(zhǎng)參數(shù)
max_allowed_packet=32M 允許插入一天數(shù)據(jù)的大小。
雙一參數(shù)優(yōu)化：
innodb_flush_log_at_trx_commit=1 每次事務(wù)提交，內(nèi)存中的數(shù)據(jù)立即刷寫(xiě)到磁盤(pán)。
sync_binlog=1:保證數(shù)據(jù)安全的機(jī)制。
刷寫(xiě)策略?xún)?yōu)化：
innodb_io_capacity=1000 ：刷寫(xiě)賬頁(yè)的速度
六、如何監(jiān)控鎖的狀態(tài)？
1.查看鎖等待。
show status like 'innodb_row_lock';
2.查看當(dāng)前運(yùn)行所有事務(wù)
select * from information_schema.innodb_trx;
3.查看等待鎖和鎖源
select * from sys.innodb_lock_waies;
---->block_pid
4.通過(guò)鎖源的pid找到執(zhí)行SQL的thread_id
select * from performance_schema.thread_id where processlist=進(jìn)程號(hào)
5.通過(guò)thread_id找到具體的所言語(yǔ)句
select * from performance_schema.events_statements_current where thread_id=id號(hào)
select * from performance_schema.events_statements_history where thread_id=id號(hào)
七、數(shù)據(jù)庫(kù)CPU爆滿(mǎn)，排查思路？
1.通過(guò)top -Hp 詳細(xì)排查線(xiàn)程
2.排查sys wait,us是否正常
3.show processlist;查看導(dǎo)致數(shù)據(jù)慢的sql語(yǔ)句
4.查看是不是有鎖等待，索引的問(wèn)題
八、你對(duì)mysql做過(guò)哪些優(yōu)化
操作系統(tǒng)上：存儲(chǔ):網(wǎng)絡(luò)：OS，
實(shí)例：參數(shù)優(yōu)化
應(yīng)用上：SQL語(yǔ)句的優(yōu)化，索引、鎖的優(yōu)化
架構(gòu)：搭建高可用、讀寫(xiě)分離、分布式架構(gòu)
架構(gòu)類(lèi)
一、Percona-XtraDB-Cluster高可用集群的工作原理
PXC最常使用以下4個(gè)端口號(hào)：
3306-數(shù)據(jù)庫(kù)對(duì)外服務(wù)的端口號(hào)。
4444-請(qǐng)求SST的端口（SST是指數(shù)據(jù)庫(kù)一個(gè)備份全量文件的傳輸。）
4567-組成員之間進(jìn)行溝通的一個(gè)端口號(hào)
4568-用于傳輸IST（相對(duì)于SST來(lái)說(shuō)的一個(gè)增量）
PXC的工作流程：
1.首先客戶(hù)端先發(fā)起一個(gè)事務(wù)，該事務(wù)先在本地執(zhí)行，執(zhí)行完成之后就要發(fā)起對(duì)事務(wù)的提交操作了。
2.在提交之前需要將產(chǎn)生的復(fù)制寫(xiě)集廣播出去，然后獲取到一個(gè)全局的事務(wù)ID號(hào)，一并傳送到另一個(gè)節(jié)點(diǎn)上面。通過(guò)合并數(shù)據(jù)之后，發(fā)現(xiàn)沒(méi)有沖突數(shù)據(jù)，執(zhí)行apply_cd和commit_cb動(dòng)作，否則就需要取消此次事務(wù)的操作。
3.而當(dāng)前server節(jié)點(diǎn)通過(guò)驗(yàn)證之后，執(zhí)行提交操作，并返回OK，如果驗(yàn)證沒(méi)通過(guò)，則執(zhí)行回滾。
4.當(dāng)然在生產(chǎn)中至少要有3個(gè)節(jié)點(diǎn)的集群環(huán)境，如果其中一個(gè)節(jié)點(diǎn)沒(méi)有驗(yàn)證通過(guò)，出現(xiàn)了數(shù)據(jù)沖突，那么此時(shí)采取的方式就是講出現(xiàn)不一致的節(jié)點(diǎn)踢出集群環(huán)境，而且它自己會(huì)執(zhí)行shutdown命令，自動(dòng)關(guān)機(jī)。
二、mycat分布式架構(gòu)，如何設(shè)計(jì)的？
三、在維護(hù)公司MHA架構(gòu)時(shí)主要做哪些工作？
1.定期的切換
2.故障監(jiān)控處理
3.主從優(yōu)化，降低延時(shí)
四、MHA高可用架構(gòu)Failover(故障轉(zhuǎn)移)原理
1.masterha_manager啟動(dòng)manager程序,讀取app1.cnf文件，獲取節(jié)點(diǎn)信息
2.調(diào)用masterha_master_monitor腳本，通過(guò)MHA用戶(hù)連接各個(gè)節(jié)點(diǎn)探測(cè)心跳
3.每?jī)擅胩綔y(cè)主庫(kù)心跳一次，探測(cè)到心跳，斷開(kāi)，一共給四次連接機(jī)會(huì)
4.四次連接不通，進(jìn)入選主流程
a.生成一下屬主，存儲(chǔ)從庫(kù)節(jié)點(diǎn)號(hào)碼
b.進(jìn)行判斷
5.選擇完新主，進(jìn)入數(shù)據(jù)補(bǔ)償間斷
a.主庫(kù)ssh能連接：將確實(shí)部分的binlog截取，存放在各個(gè)從庫(kù)，進(jìn)行補(bǔ)償
b.ssh不能連接：計(jì)算從庫(kù)的差異，互相補(bǔ)償
6.主從切換，接觸所有主從關(guān)系，構(gòu)建新的主從關(guān)系
7.調(diào)用master_ip_failover進(jìn)行vip切換，
8.調(diào)用masterha_conf_host將故障節(jié)點(diǎn)踢出集群（刪除配置文件信息）
9.manager自殺，程序退出
10調(diào)用aend_report發(fā)送告警郵件
四、MHA重要腳本的作用
Manager工具包主要包括以下幾個(gè)工具：
masterha_manger 啟動(dòng)MHA
masterha_check_ssh 檢查MHA的SSH配置狀況
masterha_check_repl 檢查MySQL復(fù)制狀況
masterha_master_monitor 檢測(cè)master是否宕機(jī)
masterha_check_status 檢測(cè)當(dāng)前MHA運(yùn)行狀態(tài)
masterha_master_switch 控制故障轉(zhuǎn)移（自動(dòng)或者手動(dòng)）
masterha_conf_host 添加或刪除配置的server信息
Node工具包主要包括以下幾個(gè)工具：
這些工具通常由MHA Manager的腳本觸發(fā)，無(wú)需人為操作
save_binary_logs 保存和復(fù)制master的二進(jìn)制日志
apply_diff_relay_logs 識(shí)別差異的中繼日志事件并將其差異的事件應(yīng)用于其他的
purge_relay_logs 清除中繼日志（不會(huì)阻塞SQL線(xiàn)程）
五、MHA的搭建過(guò)程
1.搭建1主2從，獨(dú)立節(jié)點(diǎn)、GTID
2.配置各節(jié)點(diǎn)互信無(wú)密碼認(rèn)證
3.配置所有節(jié)點(diǎn)軟連接
4.在主庫(kù)建用戶(hù)
5.軟件安裝（perl\mananger\node）
6.狀態(tài)檢查
a.互信檢查
b.主從狀態(tài)檢查
7.啟動(dòng)MHA
8.vip\binlogserver\sendreport
六、介紹你熟悉的高可用解決方案
搭建MHA架構(gòu) manager node
監(jiān)控
自動(dòng)選主
數(shù)據(jù)補(bǔ)償
應(yīng)用透明
故障通知
七、請(qǐng)介紹一下你們公司的數(shù)據(jù)庫(kù)架構(gòu)？
高可用架構(gòu)：MHA、PXC、MGC、MGR
讀寫(xiě)分離：ProxySQL、Maxscale、mysql-router、mycat
分布式架構(gòu)：mycat/sharding-jdbc
主從復(fù)制類(lèi)
一、如何為運(yùn)行了兩年的數(shù)據(jù)庫(kù)，構(gòu)建一個(gè)從庫(kù)。請(qǐng)說(shuō)明步驟，是否要停主庫(kù)？
不需要停主庫(kù)
1.主庫(kù)開(kāi)binlog,建立復(fù)制用戶(hù)，給replication slave權(quán)限
2.每個(gè)節(jié)點(diǎn)的server_id和server_uuid不同
3.初始化從庫(kù)數(shù)據(jù)
4.備份主庫(kù)數(shù)據(jù)，恢復(fù)到從庫(kù)
5.建立主從連接，change master to | start salve
二、簡(jiǎn)述主從復(fù)制原理？
1.線(xiàn)程：建立連接時(shí)和從庫(kù)進(jìn)行交互線(xiàn)程。監(jiān)控binlog狀態(tài)，傳輸binlog給從庫(kù)。
2.文件：從庫(kù)啟動(dòng)IO線(xiàn)程，接收到binlog文件寫(xiě)入到relaylog文件中，然后創(chuàng)建一個(gè)sql線(xiàn)程讀取relaylog內(nèi)容.
3.master_info會(huì)以文件或表的形式存儲(chǔ)主庫(kù)連接信息+binlog位置點(diǎn)。relaylog_info也會(huì)以文件或表的形式存儲(chǔ)從庫(kù)的位置點(diǎn)。
4.過(guò)程：
a.從庫(kù)執(zhí)行change master to ,相關(guān)信息存儲(chǔ)到master_info, 執(zhí)行start slave，啟動(dòng)IO和SQL線(xiàn)程
b.IO線(xiàn)程獲取master_info信息，請(qǐng)求鏈接主庫(kù)，主庫(kù)接收請(qǐng)求，創(chuàng)建dump線(xiàn)程監(jiān)控binlog變化，傳輸binlog給從庫(kù)IO.
c.主庫(kù)的dump線(xiàn)程根據(jù)IO線(xiàn)程提供的binlog位置點(diǎn)，截取部分日志傳給從庫(kù)IO
d.從庫(kù)IO接收到dump日志，存儲(chǔ)到relaylog中，并且將binlog為位置點(diǎn)更新到mastser_info中
e.SQL線(xiàn)程根據(jù)relaylog_info。回放最新的relaylog，并更新。一直重復(fù)以上操作。
f.relaylog用完之后會(huì)定期處理
三、如何監(jiān)控主從復(fù)制，說(shuō)明監(jiān)控要點(diǎn)？
主庫(kù)方面：
1.通過(guò)主庫(kù)線(xiàn)程 show processlist;可以查看到從庫(kù)線(xiàn)程信息
2.通過(guò) show slave hosts;可以查看到從庫(kù)的ID信息
3.重點(diǎn)監(jiān)控 show slave status\G
a.故障監(jiān)控：
b.主從延時(shí)：
四、簡(jiǎn)述遇到過(guò)的主從復(fù)制故障？如何監(jiān)控、分析、規(guī)避、處理
1.連接主庫(kù): connecting
#可能原因
連接信息有誤。
網(wǎng)絡(luò)故障。
防火墻。
最大連接數(shù)上線(xiàn)。
# 排查方法：
[root@db01 data]# mysql -urepl -p123 -h10.0.0.51 -P 3307
# 處理方法：
mysql -S /data/3308/mysql.sock -e "stop slave;reset slave all;"
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=674,
MASTER_CONNECT_RETRY=10;
start slave
2 請(qǐng)求日志: NO
主庫(kù)日志損壞。
日志起點(diǎn)寫(xiě)錯(cuò)。
server_id重復(fù)
# 排查方法
show slave status \G
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 674
Last_IO_Error: xxxx
SQL 線(xiàn)程故障： 回放中繼日志
中繼日志損壞
1. 從庫(kù) 停SQL線(xiàn)程
stop slave sql_thread ;
2. 主庫(kù)發(fā)生新的操作
create database test1;
3. 從庫(kù)刪除relaylog
rm -rf /data/3308/data/db01-relay-bin.00000*
4. 啟動(dòng)SQL線(xiàn)程
start slave sql_thread ;
修復(fù)：
1. cat /data/3308/data/relay-log.info ----> binlog 位置點(diǎn)
2. 重構(gòu)
stop slave ;
reset slave all;
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
日志回放失敗（執(zhí)行不了SQL）
# 1. 修改的對(duì)象不存在
# 2. 創(chuàng)建的對(duì)象已存在
# 3. 約束沖突
# 4. 主從配置不同
# 5. SQL_MODE不兼容
# 6. 主從版本差異
方法0：
從庫(kù)逆反操作。
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
#將同步指針向下移動(dòng)一個(gè)，如果多次不同步，可以重復(fù)操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常見(jiàn)錯(cuò)誤代碼:
1007:對(duì)象已存在
1032:無(wú)法執(zhí)行DML
1062:主鍵沖突,或約束沖突
但是，以上操作有時(shí)是有風(fēng)險(xiǎn)的，最安全的做法就是重新構(gòu)建主從。把握一個(gè)原則,一切以主庫(kù)為主.
方法三： PT工具
pt-table-checksum
pt-table-sync
方法四：從庫(kù)只讀
mysql> select @@read_only;
mysql> select @@super_read_only;
五、簡(jiǎn)述哪些情況會(huì)導(dǎo)致主從延時(shí)？如何監(jiān)控，分析，規(guī)避，處理
導(dǎo)致主從延時(shí)：
1.主庫(kù)binlog日志文件落地不及時(shí)，
2.主庫(kù)沒(méi)有GTID，主庫(kù)并發(fā)多個(gè)事務(wù)，大事務(wù)，并發(fā)事務(wù)量大，
3.單一sql線(xiàn)程，只能串行relaylog。主庫(kù)并發(fā)事務(wù)，只能是串行的。如果，大事務(wù)，并發(fā)量大，都會(huì)導(dǎo)致較高回放延時(shí)。
4.網(wǎng)絡(luò)慢，主從配置相差大
5.6版本加入了GTID功能，在傳輸時(shí)就可以并行傳輸日志了，并且GTID模式下，可以開(kāi)啟多個(gè) SQL進(jìn)程。但SQL回放時(shí)只針對(duì)不同庫(kù)并行串行
5.7版本即使不開(kāi)GTID，會(huì)自動(dòng)生成，GTID模式下，真正實(shí)現(xiàn)了并行回放
六、介紹你了解的主從復(fù)制模型？
1. 一主多從，一主一從
2.雙主
3.級(jí)聯(lián)復(fù)制 主庫(kù)復(fù)制給從庫(kù)，從庫(kù)再?gòu)?fù)制給其他從庫(kù)
4.延時(shí)從庫(kù) 人為配置從庫(kù)和這句庫(kù)延時(shí)一段時(shí)間，用來(lái)處理邏輯卷?yè)p壞
5.過(guò)濾復(fù)制 只復(fù)制部分?jǐn)?shù)據(jù)
設(shè)置白名單和黑名單，
6.半同步
七 傳統(tǒng)主從復(fù)制是異步還是同步？會(huì)不會(huì)出現(xiàn)主從不一致？出現(xiàn)有什么好的方法解決和預(yù)防？
傳統(tǒng)主從復(fù)制是異步，有可能出現(xiàn)主從不一致，使用PT工具解決。
八、延時(shí)從庫(kù)的實(shí)現(xiàn)原理？主要解決什么問(wèn)題？？如何使用延時(shí)從庫(kù)？？
實(shí)現(xiàn)：
SQL線(xiàn)程延時(shí):數(shù)據(jù)已經(jīng)寫(xiě)入relaylog中了,SQL線(xiàn)程"慢點(diǎn)"運(yùn)行
一般企業(yè)建議3-6小時(shí),具體看公司運(yùn)維人員對(duì)于故障的反應(yīng)時(shí)間
主要解決邏輯損壞：
邏輯故障的恢復(fù)思路
1.及時(shí)發(fā)現(xiàn)主庫(kù)發(fā)生了邏輯損壞
2.立即停止延時(shí)從庫(kù)的SQL線(xiàn)程
3.掛維護(hù)頁(yè)
4.截取relay進(jìn)行恢復(fù)(人為模擬SQL線(xiàn)程工作，直到drop之前)
起點(diǎn)：stop sql線(xiàn)程時(shí)的relaylog位置點(diǎn)
終點(diǎn)：drop 之前的位置點(diǎn)
5.截取的日志恢復(fù)到從庫(kù)
6.從庫(kù)替代主庫(kù)工作
九、過(guò)濾復(fù)制實(shí)現(xiàn)原理？你們公司過(guò)濾復(fù)制架構(gòu)如何設(shè)計(jì)的？
replicate_do_db=庫(kù) 白名單
replicate_ignore_db=庫(kù) 黑名單
只需要在配置文件設(shè)置想要和不想要復(fù)制的庫(kù)或表的黑白名單就可以實(shí)現(xiàn)過(guò)濾復(fù)制了。
公司一般會(huì)排除系統(tǒng)庫(kù)不復(fù)制會(huì)設(shè)置，用來(lái)復(fù)制較為重要的業(yè)務(wù)庫(kù)
十、增強(qiáng)半同步復(fù)制實(shí)現(xiàn)原理，5.6和5.7版本有什么區(qū)別？
原理：
1.主庫(kù)執(zhí)行新的事物，commit時(shí)，更新show master status\G,觸發(fā)一個(gè)信號(hào)binlog
2.binlog 線(xiàn)程接收到主庫(kù)的show master status\G信息，通知從庫(kù)日志更新了
3.從庫(kù)IO線(xiàn)程請(qǐng)求新的二進(jìn)制日志事件，
4.主庫(kù)會(huì)通過(guò)dump線(xiàn)程傳送新的日志事件，給從庫(kù)IO線(xiàn)程
5.從庫(kù)IO線(xiàn)程接收到binlog日志，當(dāng)日志寫(xiě)入到磁盤(pán)上的relaylog文件時(shí)，給主庫(kù)ACK_receiver線(xiàn)程
6.ACK_receiver線(xiàn)程觸發(fā)一個(gè)事件，告訴主庫(kù)commit可以成功了。
7.如果ACK達(dá)到了我們預(yù)設(shè)值的超時(shí)時(shí)間，半同步復(fù)制會(huì)切換為原始的異步復(fù)制。
區(qū)別：
5.6版本加入了GC機(jī)制，半同步復(fù)制開(kāi)始接受，使用after_commit機(jī)制，但是是在redo_commit之后今次那個(gè)等待ACK確認(rèn)
如果主庫(kù)redo commit間斷宕機(jī)，從庫(kù)又獲取到了binlog,會(huì)出現(xiàn)從庫(kù)比主庫(kù)數(shù)據(jù)對(duì)的問(wèn)題，導(dǎo)致數(shù)據(jù)不一致。
5.7版本以后，加入了after_sync機(jī)制，在binlog commit間斷，等待從庫(kù)ACK，不管誰(shuí)宕機(jī)，都能保證最終一致性
十一、簡(jiǎn)述MySQL Group Replication（復(fù)制組）工作原理？Paxos 分布式一致性協(xié)議工作原理？
復(fù)制組：
由多個(gè)節(jié)點(diǎn)共同組成一個(gè)復(fù)制組，一個(gè)事務(wù)提交，必須經(jīng)過(guò)組內(nèi)大多數(shù)節(jié)點(diǎn)（N/2 + 1）協(xié)議并通過(guò)，才能提交。
分布式一致性協(xié)議：
用來(lái)解決分布式中一致性問(wèn)題，分布一致性算法，最基本的功能是為了在多個(gè)進(jìn)程之間對(duì)某個(gè)值達(dá)成一致。確定一個(gè)值，一旦被寫(xiě)入就不可改變，解決多節(jié)點(diǎn)寫(xiě)入問(wèn)題。
備份恢復(fù)篇
一、在備份這塊都做過(guò)什么具體工作？
1.備份策略
2.備份檢查
3.恢復(fù)演練
4.故障快速恢復(fù)
5.遷移數(shù)據(jù)庫(kù)
二、你們公司備份策略是什么樣子的？
1.工具使用：
邏輯備份：mysqldump（MDP）
物理備份：percona Xtrabackup(PXB)
2.備份周期和方式
100G以?xún)?nèi)，每天邏輯備份全備，兩份完整備份，日志每天都備。
100G以上，使用物理備份，每周全備，其他時(shí)間做增量和日志備份
3.類(lèi)型
熱備：數(shù)據(jù)庫(kù)正常業(yè)務(wù)時(shí)備份
溫備：鎖表備份，只能查詢(xún)不能修改
冷備：關(guān)閉業(yè)務(wù)，數(shù)據(jù)庫(kù)沒(méi)有變更情況下備份
三、你們公司用什么工具備份
mysqldump (MDP)
percona Xtarbackup (XBK)
mydumper
主從
延時(shí)從庫(kù)
四、請(qǐng)介紹msyqldump核心參數(shù)，--master-data --single-transaction功能
--master-data=2
1.自動(dòng)鎖表（非innodb），global read lock
2.記錄binlog位置
--single-transaction
對(duì)innodb表開(kāi)啟快照備份
三mysqldump原理
1.提取innodb數(shù)據(jù)快照，轉(zhuǎn)換為SQL，存儲(chǔ)到sql文件中
2.非innodb表，全局鎖表，轉(zhuǎn)換為sql，轉(zhuǎn)存到sql文件
3.備份方式 create db create table insert
mysqldump的大致實(shí)現(xiàn)過(guò)程是：連接 -> 初始化信息 -> 刷新表（鎖表）-> 記錄偏移量 -> 開(kāi)啟事務(wù)（一致性快照）-> 記錄偏移量 -> 解鎖表，因?yàn)殚_(kāi)啟了一致性讀，可以得到innodb的一致性，又因?yàn)榻怄i表了，MyISAM表一致性得不到保證，所以盡量別使用MyISAM表。
四、請(qǐng)介紹xtarbackup工具備份原理
1.innobackupex在啟動(dòng)后又，會(huì)分出一個(gè)進(jìn)程，啟動(dòng)xtrabackup進(jìn)程，然后等待XBK備份完ibd文件。
2.XBK在備份innodb相關(guān)數(shù)據(jù)時(shí)，是有兩種線(xiàn)程的，1個(gè)是redo拷貝線(xiàn)程，一個(gè)是idb拷貝線(xiàn)程負(fù)責(zé)拷貝IBD文件。redo拷貝線(xiàn)程只有一個(gè)，在ibd拷貝線(xiàn)程之前啟動(dòng)，在idb線(xiàn)程結(jié)束后結(jié)束。XBK開(kāi)始執(zhí)行，先啟動(dòng)redo線(xiàn)程，從最新的checkpoint點(diǎn)開(kāi)始順序拷貝。然后再啟動(dòng)ibd數(shù)據(jù)拷貝線(xiàn)程，在拷貝idb過(guò)程中，innobackupex進(jìn)程一致處于等待狀態(tài)。（等待文件被創(chuàng)建）
3.XBK拷貝完成idb文件后,通知innobackupex，同時(shí)自己進(jìn)入等待（redo線(xiàn)程任然繼續(xù)拷貝）
4. innobackupex 收到XBK 通知后，執(zhí)行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位點(diǎn)，然后開(kāi)始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷貝非 InnoDB 文件過(guò)程中，因?yàn)閿?shù)據(jù)庫(kù)處于全局只讀狀態(tài)，如果在業(yè)務(wù)的主庫(kù)備份的話(huà)，要特別小心，非 InnoDB 表（主要是MyISAM）比較多的話(huà)整庫(kù)只讀時(shí)間就會(huì)比較長(zhǎng)，這個(gè)影響一定要評(píng)估到。
5. 當(dāng) innobackupex 拷貝完所有非 InnoDB 表文件后，通知 XBK（通過(guò)刪文件） ，同時(shí)自己進(jìn)入等待（等待另一個(gè)文件被創(chuàng)建）；
6. XBK收到 innobackupex 備份完非 InnoDB 通知后，就停止 redo 拷貝線(xiàn)程，然后通知 innobackupex redo log 拷貝完成（通過(guò)創(chuàng)建文件）；
7. innobackupex 收到 redo 備份完成通知后，就開(kāi)始解鎖，執(zhí)行 UNLOCK TABLES；
8. 最后 innobackupex 和 XBK進(jìn)程各自完成收尾工作，如資源的釋放、寫(xiě)備份元數(shù)據(jù)信息等，innobackupex 等待 XBK 子進(jìn)程結(jié)束后退出。
五 增量備份
XBK 是支持增量備份的，但是只能對(duì) InnoDB 做增量，InnoDB 每個(gè) page 有個(gè) LSN 號(hào)，LSN 是全局遞增的，page 被更改時(shí)會(huì)記錄當(dāng)前的 LSN 號(hào)，page中的 LSN 越大，說(shuō)明當(dāng)前page越新（最近被更新）。每次備份會(huì)記錄當(dāng)前備份到的LSN（xtrabackup_checkpoints 文件中），增量備份就是只拷貝LSN大于上次備份的page，比上次備份小的跳過(guò)，每個(gè) ibd 文件最終備份出來(lái)的是增量 delta 文件。
MyISAM 是沒(méi)有增量的機(jī)制的，每次增量備份都是全部拷貝的。
增量備份過(guò)程和全量備份一樣，只是在 ibd 文件拷貝上有不同。
六、恢復(fù)過(guò)程
如果看恢復(fù)備份集的日志，會(huì)發(fā)現(xiàn)和 mysqld 啟動(dòng)時(shí)非常相似，其實(shí)備份集的恢復(fù)就是類(lèi)似 mysqld crash后，做一次 crash recover。
恢復(fù)的目的是把備份集中的數(shù)據(jù)恢復(fù)到一個(gè)一致性位點(diǎn)，所謂一致就是指原數(shù)據(jù)庫(kù)某一時(shí)間點(diǎn)各引擎數(shù)據(jù)的狀態(tài)，比如 MyISAM 中的數(shù)據(jù)對(duì)應(yīng)的是 15:00 時(shí)間點(diǎn)的，InnoDB 中的數(shù)據(jù)對(duì)應(yīng)的是 15:20 的，這種狀態(tài)的數(shù)據(jù)就是不一致的。PXB 備份集對(duì)應(yīng)的一致點(diǎn)，就是備份時(shí)FTWRL的時(shí)間點(diǎn)，恢復(fù)出來(lái)的數(shù)據(jù)，就對(duì)應(yīng)原數(shù)據(jù)庫(kù)FTWRL時(shí)的狀態(tài)。
因?yàn)閭浞輹r(shí) FTWRL 后，數(shù)據(jù)庫(kù)是處于只讀的，非 InnoDB 數(shù)據(jù)是在持有全局讀鎖情況下拷貝的，所以非 InnoDB 數(shù)據(jù)本身就對(duì)應(yīng) FTWRL 時(shí)間點(diǎn)；InnoDB 的 ibd 文件拷貝是在 FTWRL 前做的，拷貝出來(lái)的不同 ibd 文件最后更新時(shí)間點(diǎn)是不一樣的，這種狀態(tài)的 ibd 文件是不能直接用的，但是 redo log 是從備份開(kāi)始一直持續(xù)拷貝的，最后的 redo 日志點(diǎn)是在持有 FTWRL 后取得的，所以最終通過(guò) redo 應(yīng)用后的 ibd 數(shù)據(jù)時(shí)間點(diǎn)也是和 FTWRL 一致的。
所以恢復(fù)過(guò)程只涉及 InnoDB 文件的恢復(fù)，非 InnoDB 數(shù)據(jù)是不動(dòng)的。備份恢復(fù)完成后，就可以把數(shù)據(jù)文件拷貝到對(duì)應(yīng)的目錄，然后通過(guò)mysqld來(lái)啟動(dòng)了。
七、同時(shí)晚上23：00開(kāi)始備份，23:30分結(jié)束。Mdp和xbk兩個(gè)工具理論上能將數(shù)據(jù)恢復(fù)至幾點(diǎn)？
MDP :23.00
XBK:23.30
八、XBK的增量備份時(shí)如何實(shí)現(xiàn)的？
基于上一次備份LSN號(hào)變化過(guò)的數(shù)據(jù)頁(yè)進(jìn)行備份，災(zāi)備份同時(shí)產(chǎn)生的新的變更，會(huì)將redo備份、
第一次增量是依賴(lài)于全備的，將來(lái)恢復(fù)也要合并到全備中，在進(jìn)行統(tǒng)一恢復(fù)
九、Xtrabackup增量備份恢復(fù)要注意什么？
1.增量備份僅能應(yīng)用于InnoDB或XtraDB表，對(duì)于MyISAM表而言，執(zhí)行增量備份時(shí)其實(shí)進(jìn)行的是完全備份。
2.增量備份需要使用參數(shù)–incremental指定需要備份到哪個(gè)目錄，使用incremental-dir指定全備目錄；
3.進(jìn)行數(shù)據(jù)備份時(shí)，需要使用參數(shù)–apply-log redo-only先合并全備數(shù)據(jù)目錄數(shù)據(jù)，確保全備數(shù)據(jù)目錄數(shù)據(jù)的一致性；
4.再將增量備份數(shù)據(jù)使用參數(shù)–incremental-dir合并到全備數(shù)據(jù)當(dāng)中；
5.最后通過(guò)最后的全備數(shù)據(jù)進(jìn)行恢復(fù)數(shù)據(jù)，注意，如果有多個(gè)增量備份，需要逐一合并到全備數(shù)據(jù)當(dāng)中，再進(jìn)行恢復(fù)。
十、Mysqldump和xtrabackup 備份如何實(shí)現(xiàn)基于時(shí)間點(diǎn)的恢復(fù)？
MDP的--master-data=2參數(shù),自動(dòng)記錄了位置點(diǎn)信息，結(jié)合binlog恢復(fù)。
XBK的xtrabackup_binlog_info文件中記錄了binlog 和GTID的信息,結(jié)合binlog恢復(fù)
