此文是根據楊尚剛在【QCON高可用架構羣】中,針對MySQL在單表海量記錄等場景下,業界廣泛關注的MySQL問題的經驗分享整理而成,轉發請註明出處。
楊尚剛,美圖公司數據庫高級DBA,負責美圖後端數據存儲平臺建設和架構設計。前新浪高級數據庫工程師,負責新浪微博核心數據庫架構改造優化,以及數據庫相關的服務器存儲選型設計。
前言
MySQL數據庫大家應該都很熟悉,而且隨着前幾年的阿里的去IOE,MySQL逐漸引起更多人的重視。
MySQL歷史
-
1979年,Monty Widenius寫了最初的版本,96年發佈1.0
-
1995-2000年,MySQL AB成立,引入BDB
-
2000年4月,集成MyISAM和replication
-
2001年,Heikki Tuuri向MySQL建議集成InnoDB
-
2003發佈5.0,提供了視圖、存儲過程等功能
-
2008年,MySQL AB被Sun收購,09年推出5.1
-
2009年4月,Oracle收購Sun,2010年12月推出5.5
-
2013年2月推出5.6 GA,5.7開發中
MySQL的優點
-
使用簡單
-
開源免費
-
擴展性“好”,在一定階段擴展性好
-
社區活躍
-
性能可以滿足互聯網存儲和性能需求,離不開硬件支持
上面這幾個因素也是大多數公司選擇考慮MySQL的原因。不過MySQL本身存在的問題和限制也很多,有些問題點也經常被其他數據庫吐槽或鄙視
MySQL存在的問題
-
優化器對複雜SQL支持不好
-
對SQL標準支持不好
-
大規模集羣方案不成熟,主要指中間件
-
ID生成器,全局自增ID
-
異步邏輯複製,數據安全性問題
-
Online DDL
-
HA方案不完善
-
備份和恢復方案還是比較複雜,需要依賴外部組件
-
展現給用戶信息過少,排查問題困難
-
衆多分支,讓人難以選擇
看到了剛纔講的MySQL的優勢和劣勢,可以看到MySQL面臨的問題還是遠大於它的優勢的,很多問題也是我們實際需要在運維中優化解決的,這也是MySQL DBA的一方面價值所在。並且MySQL的不斷髮展也離不開社區支持,比如Google最早提交的半同步patch,後來也合併到官方主線。Facebook Twitter等也都開源了內部使用MySQL分支版本,包含了他們內部使用的patch和特性。
數據庫開發規範
數據庫開發規範定義:開發規範是針對內部開發的一系列建議或規則, 由DBA制定(如果有DBA的話)。
開發規範本身也包含幾部分:基本命名和約束規範,字段設計規範,索引規範,使用規範。
規範存在意義
-
保證線上數據庫schema規範
-
減少出問題概率
-
方便自動化管理
-
規範需要長期堅持,對開發和DBA是一個雙贏的事情
想想沒有開發規範,有的開發寫出各種全表掃描的SQL語句或者各種奇葩SQL語句,我們之前就看過開發寫的SQL 可以打印出好幾頁紙。這種造成業務本身不穩定,也會讓DBA天天忙於各種救火。
基本命名和約束規範
-
表字符集選擇UTF8 ,如果需要存儲emoj表情,需要使用UTF8mb4(MySQL 5.5.3以後支持)
-
存儲引擎使用InnoDB
-
變長字符串儘量使用varchar varbinary
-
不在數據庫中存儲圖片、文件等
-
單表數據量控制在1億以下
-
庫名、表名、字段名不使用保留字
-
庫名、表名、字段名、索引名使用小寫字母,以下劃線分割 ,需要見名知意
-
庫表名不要設計過長,儘可能用最少的字符表達出表的用途
字段規範
-
所有字段均定義爲NOT NULL ,除非你真的想存Null
-
字段類型在滿足需求條件下越小越好,使用UNSIGNED存儲非負整數 ,實際使用時候存儲負數場景不多
-
使用TIMESTAMP存儲時間
-
使用varchar存儲變長字符串 ,當然要注意varchar(M)裏的M指的是字符數不是字節數;使用UNSIGNED INT存儲IPv4 地址而不是CHAR(15) ,這種方式只能存儲IPv4,存儲不了IPv6
-
使用DECIMAL存儲精確浮點數,用float有的時候會有問題
-
少用blob text
關於爲什麼定義不使用Null的原因
* 1.浪費存儲空間,因爲InnoDB需要有額外一個字節存儲
* 2.表內默認值Null過多會影響優化器選擇執行計劃
關於使用datatime和timestamp,現在在5.6.4之後又有了變化,使用二者存儲在存儲空間上大差距越來越小 ,並且本身datatime存儲範圍就比timestamp大很多,timestamp只能存儲到2038年
索引規範
-
單個索引字段數不超過5,單表索引數量不超過5,索引設計遵循B+ Tree索引最左前綴匹配原則
-
選擇區分度高的列作爲索引
-
建立的索引能覆蓋80%主要的查詢,不求全,解決問題的主要矛盾
-
DML和order by和group by字段要建立合適的索引
-
避免索引的隱式轉換
-
避免冗餘索引
關於索引規範,一定要記住索引這個東西是一把雙刃劍,在加速讀的同時也引入了很多額外的寫入和鎖,降低寫入能力,這也是爲什麼要控制索引數原因。之前看到過不少人給表裏每個字段都建了索引,其實對查詢可能起不到什麼作用。
冗餘索引例子
-
idx_abc(a,b,c)
-
idx_a(a) 冗餘
-
idx_ab(a,b) 冗餘
隱式轉換例子
字段:remark
varchar(50) NOT Null
MySQL>SELECT
id
,
gift_code
FROM gift WHERE
deal_id
= 640 AND remark=115127; 1 row in set (0.14 sec)
MySQL>SELECT
id
,
gift_code
FROM pool_gift WHEREdeal_id
= 640 AND remark=‘115127’; 1 row in set (0.005 sec)
字段定義爲varchar,但傳入的值是個int,就會導致全表掃描,要求程序端要做好類型檢查
SQL類規範
-
儘量不使用存儲過程、觸發器、函數等
-
避免使用大表的JOIN,MySQL優化器對join優化策略過於簡單
-
避免在數據庫中進行數學運算和其他大量計算任務
-
SQL合併,主要是指的DML時候多個value合併,減少和數據庫交互
-
合理的分頁,尤其大分頁
-
UPDATE、DELETE語句不使用LIMIT ,容易造成主從不一致
數據庫運維規範
運維規範主要內容
-
SQL審覈,DDL審覈和操作時間,尤其是OnlineDDL
-
高危操作檢查,Drop前做好數據備份
-
權限控制和審計
-
日誌分析,主要是指的MySQL慢日誌和錯誤日誌
-
高可用方案
-
數據備份方案
版本選擇
-
MySQL社區版,用戶羣體最大
-
MySQL企業版,收費
-
Percona Server版,新特性多
-
MariaDB版,國內用戶不多
建議選擇優先級爲:MySQL社區版 > Percona Server > MariaDB > MySQL 企業版
不過現在如果大家使用RDS服務,基本還以社區版爲主
Online DDL問題
原生MySQL執行DDL時需要鎖表,且鎖表期間業務是無法寫入數據的,對服務影響很大,MySQL對這方面的支持是比較差的。大表做DDL對DBA來說是很痛苦的,相信很多人經歷過。如何做到Online DDL呢,是不是就無解了呢?當然不是!
上面表格裏提到的 Facebook OSC和5.6 OSC也是目前兩種比較靠譜的方案
MySQL 5.6的OSC方案還是解決不了DDL的時候到從庫延時的問題,所以現在建議使用Facebook OSC這種思路更優雅
下圖是Facebook OSC的思路
後來Percona公司根據Facebook OSC思路,用perl重寫了一版,就是我們現在用得很多的pt-online-schema-change,軟件本身非常成熟,支持目前主流版本。
使用pt-online-schema-change的優點有:
-
1.無阻塞寫入
-
2.完善的條件檢測和延時負載策略控制
值得一提的是,騰訊互娛的DBA在內部分支上也實現了Online DDL,之前測試過確實不錯,速度快,原理是通過修改InnoDB存儲格式來實現。
使用pt-online-schema-change的限制有:
-
改表時間會比較長(相比直接alter table改表)
-
修改的表需要有唯一鍵或主鍵
-
在同一端口上的併發修改不能太多
可用性
關於可用性,我們今天分享一種無縫切主庫方案,可以用於日常切換,使用思路也比較簡單
在正常條件下如何無縫去做主庫切換,核心思路是讓新主庫和從庫停在相同位置,主要依賴slave start until 語句,結合雙主結構,考慮自增問題。
MySQL集羣方案:
-
集羣方案主要是如何組織MySQL實例的方案
-
主流方案核心依然採用的是MySQL原生的複製方案
-
原生主從同步肯定存在着性能和安全性問題
MySQL半同步複製:
現在也有一些理論上可用性更高的其它方案
-
Percona XtraDB Cluster(沒有足夠的把控力度,不建議上)
-
MySQL Cluster(有官方支持,不過實際用的不多)
紅框內是目前大家使用比較多的部署結構和方案。當然異常層面的HA也有很多第三方工具支持,比如MHA、MMM等,推薦使用MHA
sharding拆分問題
-
Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
-
sharding是按照一定規則數據重新分佈的方式
-
主要解決單機寫入壓力過大和容量問題
-
主要有垂直拆分和水平拆分兩種方式
-
拆分要適度,切勿過度拆分
-
有中間層控制拆分邏輯最好,否則拆分過細管理成本會很高
曾經管理的單表最大60億+,單表數據文件大小1TB+,人有時候就要懶一些
上圖是水平拆分和垂直拆分的示意圖
數據庫備份
首先要保證的,最核心的是數據庫數據安全性。數據安全都保障不了的情況下談其他的指標(如性能等),其實意義就不大了。
備份的意義是什麼呢?
-
數據恢復!
-
數據恢復!
-
數據恢復!
目前備份方式的幾個緯度:
-
全量備份 VS 增量備份
-
熱備 VS 冷備
-
物理備份 VS 邏輯備份
-
延時備份
-
全量binlog備份
建議方式:
-
熱備+物理備份
-
核心業務:延時備份+邏輯備份
-
全量binlog備份
借用一下某大型互聯網公司做的備份系統數據:一年7000+次擴容,一年12+次數據恢復,日誌量每天3TB,數據總量2PB,每天備份數據量百TB級,全年備份36萬次,備份成功了99.9%。
主要做的幾點:
-
備份策略集中式調度管理
-
xtrabackup熱備
-
備份結果統計分析
-
備份數據一致性校驗
-
採用分佈式文件系統存儲備份
備份系統採用分佈式文件系統原因:
-
解決存儲分配的問題
-
解決存儲NFS備份效率低下問題
-
存儲集中式管理
-
數據可靠性更好
使用分佈式文件系統優化點:
* Pbzip壓縮,降低多副本存儲帶來的存儲成本,降低網絡帶寬消耗
* 元數據節點HA,提高備份集羣的可用性
* erasure code方案調研
數據恢復方案
目前的MySQL數據恢復方案主要還是基於備份來恢復,可見備份的重要性。比如我今天下午15點刪除了線上一張表,該如何恢復呢?首先確認刪除語句,然後用備份擴容實例啓動,假設備份時間點是凌晨3點,就還需要把凌晨3點到現在關於這個表的binlog導出來,然後應用到新擴容的實例上,確認好恢復的時間點,然後把刪除表的數據導出來應用到線上。
性能優化
複製優化
MySQL複製:
-
是MySQL應用得最普遍的應用技術,擴展成本低
-
邏輯複製
-
單線程問題,從庫延時問題
-
可以做備份或讀複製
問題很多,但是能解決基本問題
上圖是MySQL複製原理圖,紅框內就是MySQL一直被人詬病的單線程問題
單線程問題也是MySQL主從延時的一個重要原因,單線程解決方案:
-
官方5.6+多線程方案
-
Tungsten爲代表的第三方並行複製工具
-
sharding
上圖是MySQL5.6 目前實現的並行複製原理圖,是基於庫級別的複製,所以如果你只有一個庫,使用這個意義不大
當然MySQL也認識到5.6這種並行的瓶頸所在,所以在5.7引入了另外一種並行複製方式,基於logical timestamp的並行複製,並行複製不再受限於庫的個數,效率會大大提升
上圖是5.7的logical timestamp的複製原理圖
剛纔我也提到MySQL原來只支持異步複製,這種數據安全性是非常差的,所以後來引入了半同步複製,從5.5開始支持
上圖是原生異步複製和半同步複製的區別。可以看到半同步通過從庫返回ACK這種方式確認從庫收到數據,數據安全性大大提高
在5.7之後,半同步也可以配置你指定多個從庫參與半同步複製,之前版本都是默認一個從庫
對於半同步複製效率問題有一個小的優化,就是使用5.6+的mysqlbinlog以daemon方式作爲從庫,同步效率會好很多
關於更安全的複製,MySQL 5.7也是有方案的,方案名叫Group replication 官方多主方案,基於Corosync實現
主從延時問題
原因:一般都會做讀寫分離,其實從庫壓力反而比主庫大/從庫讀寫壓力大非常容易導致延時。
解決方案:
-
首先定位延時瓶頸
-
如果是IO壓力,可以通過升級硬件解決,比如替換SSD等
-
如果IO和CPU都不是瓶頸,非常有可能是SQL單線程問題,解決方案可以考慮剛纔提到的並行複製方案
-
如果還有問題,可以考慮sharding拆分方案
提到延時不得不提到很坑人的Seconds behind master,使用過MySQL的應該很熟悉
這個值的源碼裏算法
long time_diff= ((long)(time(0) – mi->rli.last_master_timestamp) – mi->clock_diff_with_master);
Secondsbehindmaster來判斷延時不可靠,在網絡抖動或者一些特殊參數配置情況下,會造成這個值是0但其實延時很大了。通過heartbeat表插入時間戳這種機制判斷延時是更靠譜的
複製注意點:
-
Binlog格式,建議都採用row格式,數據一致性更好
-
Replication filter應用
主從數據一致性問題:
-
row格式下的數據恢復問題
InnoDB優化
成熟開源事務存儲引擎,支持ACID,支持事務四個隔離級別,更好的數據安全性,高性能高併發,MVCC,細粒度鎖,支持O_DIRECT。
主要優化參數:
-
innodbfileper_table =1
-
innodbbufferpool_size,根據數據量和內存合理設置
-
innodbflushlog_attrxcommit= 0 1 2
-
innodblogfile_size,可以設置大一些
-
innodbpagesize
-
Innodbflushmethod = o_direct
-
innodbundodirectory 放到高速設備(5.6+)
-
innodbbufferpool_dump
-
atshutdown ,bufferpool dump (5.6+)
上圖是5.5 4G的redo log和5.6 設置大於4G redo log文件性能對比,可以看到穩定性更好了。innodblogfile_size設置還是很有意義的
InnoDB比較好的特性:
-
Bufferpool預熱和動態調整大小,動態調整大小需要5.7支持
-
Page size自定義調整,適應目前硬件
-
InnoDB壓縮,大大降低數據容量,一般可以壓縮50%,節省存儲空間和IO,用CPU換空間
-
Transportable tablespaces,遷移ibd文件,用於快速單表恢復
-
Memcached API,full text,GIS等
InnoDB在SSD上的優化:
-
在5.5以上,提高innodbwriteiothreads和innodbreadiothreads
-
innodbiocapacity需要調大
-
日誌文件和redo放到機械硬盤,undo放到SSD,建議這樣,但必要性不大
-
atomic write,不需要Double Write Buffer
-
InnoDB壓縮
-
單機多實例
也要搞清楚InnoDB哪些文件是順序讀寫,哪些是隨機讀寫
隨機讀寫:
-
datadir
-
innodbdata file_path
-
innodbundo directory
順序讀寫:
-
innodbloggrouphomedir
-
log-bin
InnoDB VS MyISAM:
-
數據安全性至關重要,InnoDB完勝,曾經遇到過一次90G的MyISAM表repair,花了兩天時間,如果在線上幾乎不可忍受
-
併發度高
-
MySQL 5.5默認引擎改爲InnoDB,標誌着MyISAM時代的落幕
TokuDB:
-
支持事務 ACID 特性,支持多版本控制(MVCC)
-
基於Fractal Tree Index,非常適合寫入密集場景
-
高壓縮比,原生支持Online DDL
-
主流分支都支持,收費轉開源 。目前可以和InnoDB媲美的存儲引擎
目前主流使用TokuDB主要是看中了它的高壓縮比,Tokudb有三種壓縮方式:quicklz、zlib、lzma,壓縮比依次更高。現在很多使用zabbix的後端數據表都採用的TokuDB,寫入性能好,壓縮比高。
下圖是我之前做的測試對比和InnoDB
上圖是sysbench測試的和InnoDB性能對比圖,可以看到TokuDB在測試過程中寫入穩定性是非常好的。
tokudb存在的問題:
-
官方分支還沒很好的支持
-
熱備方案問題,目前只有企業版纔有
-
還是有bug的,版本更新比較快,不建議在覈心業務上用
比如我們之前遇到過一個問題:TokuDB的內部狀態顯示上一次完成的checkpoint時間是“Jul 17 12:04:11 2014”,距離當時發現現在都快5個月了,結果堆積了大量redo log不能刪除,後來只能重啓實例,結果重啓還花了七八個小時
MySQL優化相關的case
Query cache,MySQL內置的查詢加速緩存,理念是好的,但設計不夠合理,有點out。
鎖的粒度非常大MySQL 5.6默認已經關閉
When the query cache helps, it can help a lot. When it hurts, it can hurt a lot.明顯前半句已經沒有太大用處,在高併發下非常容易遇到瓶頸。
關於事務隔離級別 ,InnoDB默認隔離級別是可重複讀級別,當然InnoDB雖然是設置的可重複讀,但是也是解決了幻讀的,建議改成讀已提交級別,可以滿足大多數場景需求,有利於更高的併發,修改transaction-isolation。
上圖是一個比較經典的死鎖case,有興趣可以測試下
關於SSD
關於SSD,還是提一下吧。某知名大V說過“最近10年對數據庫性能影響最大的是閃存”,穩定性和性能可靠性已經得到大規模驗證,多塊SATA SSD做Raid5,推薦使用。採用PCIe SSD,主流雲平臺都提供SSD雲硬盤支持。
最後說一下大家關注的單表60億記錄問題,表裏數據也是線上比較核心的。
先說下當時情況,表結構比較簡單,都是bigint這種整型,索引比較多,應該有2-3個,單錶行數60億+,單表容量1.2TB左右,當然內部肯定是有碎片的。
形成原因:歷史遺留問題,按照我們前面講的開發規範,這個應該早拆分了,當然不拆有幾個原因:
-
性能未遇到瓶頸 ,主要原因
-
DBA比較“懶“
-
想看看InnoDB的極限,挑戰一下。不過風險也是很大的,想想如果在一個1.2TB表上加個字段加個索引,那感覺絕對酸爽。還有就是單表恢復的問題,恢復時間不可控。
我們後續做的優化 ,採用了剛纔提到的TokuDB,單表容量在InnoDB下1TB+,使用Tokudb的lzma壓縮到80GB,壓縮效果非常好。這樣也解決了單表過大恢復時間問題,也支持online DDL,基本達到我們預期。
今天講的主要針對MySQL本身優化和規範性質的東西,還有一些比較好的運維經驗,希望大家能有所收穫。今天這些內容是爲後續數據庫做平臺化的基礎。我今天分享就到這裏,謝謝大家。
QA
Q1:use schema;select * from table; 和select * from schema.table;兩種寫法有什麼不一樣嗎?會對主從同步有影響嗎?
對於主從複製來說執行效率上差別不大,不過在使用replication filter時候這種情況需要小心,應該要使用ReplicateWildIgnoreTable這種參數,如果不使用帶wildignore,第一種方式會有問題,過濾不起作用。
Q2:對於用於MySQL的ssd,測試方式和ssd的參數配置方面,有沒有好的建議?主要針對ssd的配置哈
關於SATA SSD配置參數,建議使用Raid5,想更保險使用Raid50,更土豪使用Raid 10
上圖是主要的參數優化,性能提升最大的是第一個修改調度算法的
Q3:數據庫規範已制定好,如何保證開發人員必須按照規範來開發?
關於數據庫規範實施問題,也是有兩個方面吧,第一、定期給開發培訓開發規範,讓開發能更瞭解。第二、還是在流程上規範,比如把我們日常通用的建表和字段策略固化到程序,做成自動化審覈系統。這兩方面結合 效果會比較好。
Q4:如何最大限度提高innodb的命中率?
這個問題前提是你的數據要有熱點,讀寫熱點要有交集,否則命中率很難提高。在有熱點的前提下,也要求你的你的內存要足夠大,能夠存更多的熱點數據。儘量不要做一些可能污染bufferpool的操作,比如全表掃描這種。
Q5:主從複製的情況下,如果有CAS這樣的需求,是不是隻能強制連主庫?因爲有延遲的存在,如果讀寫不在一起的話,會有髒數據。
如果有CAS需求,確實還是直接讀主庫好一些,因爲異步複製還是會有延遲的。只要SQL優化的比較好,讀寫都在主庫也是沒什麼問題的。
Q6:關於開發規範,是否有必要買國標?
這個國標是什麼東西,不太瞭解。不過從字面看,國標應該也是偏學術方面的,在具體工程實施時候未必能用好。
Q7:主從集羣能不能再細化一點那?不知道這樣問合適不?
看具體哪方面吧。主從集羣每個小集羣一般都是採用一主多從方式,每個小集羣對應特定的一組業務。然後監控備份和HA都是在每個小集羣實現。
Q8:如何跟蹤數據庫table某個字段值發生變化?
追蹤字段值變化可以通過分析row格式binlog好一些。比如以前同事就是通過自己開發的工具來解析row格式binlog,跟蹤數據行變化。
Q9:對超大表水平拆分,在使用MySQL中間件方面有什麼建議和經驗分享?
對於超大表水平拆分,在中間件上經驗不是很多,早期人肉搞過幾次。也使用過自己研發的數據庫中間件,不過線上應用的規模不大。關於目前衆多的開源中間件裏,360的atlas是目前還不錯的,他們公司內部應用的比較多。
Q10:我們用的MySQL proxy做讀負載,但是少量數據壓力下並沒有負載,請問有這回事嗎?
少量數據壓力下,並沒有負載 ,這個沒測試過,不好評價
Q11:對於binlog格式,爲什麼只推薦row,而不用網上大部分文章推薦的Mix ?
這個主要是考慮數據複製的可靠性,row更好。mixed含義是指如果有一些容易導致主從不一致的SQL ,比如包含UUID函數的這種,轉換爲row。既然要革命,就搞的徹底一些。這種mix的中間狀態最坑人了。
Q12: 讀寫分離,一般是在程序裏做,還是用proxy ,用proxy的話一般用哪個?
這個還是獨立寫程序好一些,與程序解耦方便後期維護。proxy國內目前開源的比較多,選擇也要慎重。
Q13: 我想問一下關於mysql線程池相關的問題,什麼情況下適合使用線程池,相關的參數應該如何配置,老師有這方面的最佳實踐沒有?
線程池這個我也沒測試過。從原理上來說,短鏈接更適合用線程池方式,減少建立連接的消耗。這個方面的最佳配置,我還沒測試過,後面測試有進展可以再聊聊。
Q14: 誤刪數據這種,數據恢復流程是怎麼樣的(從庫也被同步刪除的情況)?
看你刪除數據的情況,如果只是一張表,單表在幾GB或幾十GB。如果能有延時備份,對於數據恢復速度是很有好處的。恢復流程可以參考我剛纔分享的部分。目前的MySQL數據恢復方案主要還是基於備份來恢復 ,可見備份的重要性。比如我今天下午15點刪除了線上一張表,該如何恢復呢。首先確認刪除語句,然後用備份擴容實例啓動,假設備份時間點是凌晨3點。就還需要把凌晨3點到現在關於這個表的binlog導出來,然後應用到新擴容的實例上。確認好恢復的時間點,然後把刪除表的數據導出來應用到線上。
Q15: 關於備份,binlog備份自然不用說了,物理備份有很多方式,有沒有推薦的一種,邏輯備份在量大的時候恢復速度比較慢,一般用在什麼場景?
物理備份採用xtrabackup熱備方案比較好。邏輯備份一般用在單表恢復效果會非常好。比如你刪了一個2G表,但你總數據量2T,用物理備份就會要慢了,邏輯備份就非常有用了。