RDS最佳實踐(一)—如何選擇你的RDS

在去年雙11以前，爲了幫助商家準備天貓雙11的大促，讓用戶更好的使用RDS，把RDS的性能發揮到最佳，保障雙11當天面對爆發性增長的壓力，不會因爲RDS的瓶頸致使系統出現問題，編寫了 RDS的最佳實踐 。該文檔的內容所有出自於生產實踐，但因爲篇幅的限制，我只是把其中的概要羅列到了ppt中，並無展開詳細的介紹，後續計劃寫一個系列，把ppt中的內容進一步展開來說一講，也算是對RDS用戶的一個交代。

我該如何選擇RDS？我要購買多大規格的RDS？RDS的鏈接數，iops指的是什麼？上訴這些問題相信是每個RDS用戶在開始使用的時候都會有這樣的疑問。首先咱們要了解一下RDS的組成包括哪一些，從阿里雲官網的購買頁面中咱們能夠看到RDS包括瞭如下參數：數據庫類型，版本，存儲空間，規格：內存+鏈接數+io，地域，那咱們就一個個來分析一下：

一.數據庫的類型：

RDS目前支持的數據庫類型有兩種：mysql，sqlserver，爲何這裏要特別提出來說一講？緣由有如下兩個方面：
a.因爲受到sqlserver和windows license的影響，sqlserver價格會比mysql高出近50%，一個2G Mem+50GB Disk的Mysql一年的價格是：4480 RMB；一個2G Mem+50GB Disk的Sqlserver一年的價格是：6420 RMB;
b.sqlserver處於閉源狀態，在出現異常疑難問題排查的時候，每每須要藉助微軟官方的幫助，同時RDS若是想在sqlserver上面定製出一些本身特點的功能時候，每每其封閉的協議讓RDS望而退步；相對於mysql的開源而言，RDS依託了阿里強大的mysql內核開發和運維經驗，可以很好的定製出一些RDS本身的特點功能，在出現疑難問題上可以迅速的進行debug排查。
在阿里的電商雲平臺聚石塔，已經有大量的isv，商家正在改造本身的後臺系統從sqlserver轉向的mysql，你還在猶豫什麼？

二.數據庫的版本：
RDS mysql目前支持5.5和5.1兩個版本，sqlserver支持2008一個版本,一般在高版本中會：修復掉低版本中一些bug提升系統的穩定和安全性，優化改進低版本的設計提高系統的性能，推出一些新的功能豐富提高系統的易用性。因此這裏咱們咱們以mysql爲例，看一看在5.5與5.1相比較有哪些改動：
1)默認存儲引擎更改成InnoDB
2)提升性能和可擴展性
. 提升了默認線程併發數(innodb_thread_concurrency)
. 後臺輸入/輸出線程控制（innodb_read_io_threads、innodb_write_io_threads）
. 適應性散列索引(Hash Index)控制，用戶能夠關閉適應性散列功能
. 插入緩衝（Insert Buffering）控制，用戶能夠關閉innodb的插入緩衝功能
. 恢復組提交（Restored Group Commit）
. 多個回滾段（Multiple Rollback Segments）,以前的innodb版本最大能處理1023個併發處理操做，如今mysql5.5能夠處理高達128K的併發事物，
. 改善了日誌系統互斥和單獨刷新（Flush）列表互斥
. 改善清除程序進度，在mysql5.5中清楚操做線程是獨立的線程，並支持併發，可使用innodb_purge_treads配置。

3)提升實用性
. 半同步複製（Semi-synchronous Replication）
. 複製Heartbeat
. 中繼日誌自動恢復（Automatic Relay Log Recovery）

4)提升易管理性和效率
. 創建快速索引（Faster Index Creation）
. 高效的數據壓縮（Efficient Data Compression）
. 爲大物件和可變長度列提供高效存儲
. 增長了INFORMATION_SCHEMA表，新的表提供了與InnoDB壓縮和事務處理鎖定有關的具體信息
. 支持utf8mb4字符集

5)提升可用性
. 新的表/索引分區選項。MySQL5.5將表和索引RANG和LIST分區範圍擴展到了非整數列和日期，並增長了在多個列上分區的能力。

6)改善檢測和診斷
. Mysql5.5引入了一種新的性能架構(performancn_shema,P_S),用於監控mysql監控服務器運行時的性能。

有了這麼多功能的改進提高，還有什麼理由不使用5.5.

三.存儲空間：

在RDS的工單問題中，空間問題的諮詢應該能夠算得上是top 5，當RDS的實際使用空間超過了購買的空間後，實例就會被鎖定了，這樣就會致使應用沒法再寫入，更新數據，形成應用的報錯，在RDS的控制檯中能夠設定空間的報警閥值，當實例空間到達報警閥值後用戶就會收到報警短信，這個時候用戶則須要對判斷當前的空間增加是否合理，若是合理的增加則須要對實例的進行彈性升級，若是增加不合理，則須要進行快速的判斷。因此在這裏咱們就須要瞭解RDS的空間組成到底包括了哪些？

RDS的實例空間主要包括了：數據文件,日誌文件，其餘文件（包括系統文件，臨時文件）

下面咱們來詳細介紹一下這些文件組成：

1. 數據文件：顧名思義該文件空間則是指的存放用數據的文件，對應到數據庫中就是一張張的表，表的組成主要包括：數據和索引兩類，因此當你看到你的數據文件佔用實例的空間很是多的時候，你須要看一下究竟是哪一張表佔用了個人空間，RDS在控制檯中提供了：性能優化–>大表優化的性能報表，用戶則能夠在這裏找到系統中佔用最大的文件。可是凡事須要未雨綢繆，咱們在設計應用的時候，就要考慮將來數據的增加趨勢（數據的生命保留週期）,合理的設計數據的存放位置(存放文件or數據庫),存儲格式（數據類型，字段大小），存放方式（存儲引擎選擇，分區仍是分表）。下圖的案例案例中，數據空間佔用了實例大量的空間，用戶能夠經過排查數據庫中究竟是哪一張表佔用致使的（能夠參考性能優化–>大表優化）

        

2. 日誌文件：RDS採用的主備M-M的高可用架構，其主備之間的數據同步依靠日誌的方式，mysql：binlog，sqlserver：transaction log；同時RDS支持將實例恢復到任何一個時間點，這個功能須要依靠運用備份和日誌。爲了減小日誌空間對用戶的空間的佔用，RDS mysql會定時的把日誌備份到oss中，而後再將其清除，這樣用戶須要下載RDS日誌的時候能夠從oss中獲取；對於sqlserver，rds對按期的對數據庫進行備份，而後將事務日誌進行回收。當日志空間出現異常的時候，以下圖，因爲應用寫入數據壓力過大，致使binlog日誌增長的速度大於了RDS上傳到oss的速度，形成了binlog日誌增加迅猛，這時候須要用戶對數據庫的update，insert，delete進行優化，減少對數據庫的變動操做：
   
3. 其餘文件：
   a.系統文件，每一個數據庫在安裝的時候會初始化一些系統文件，這些系統文件是數據庫正常運行的前提，mysql：ibdata1，ib_logfile0，sqlserver：MSDBLog，master.mdf，下面的這幅圖反映了RDS"其餘文件"佔用達到了很是多的問題，能夠參考blog： ibdata1文件持續增長的問題定位

b.臨時文件：一般能夠理解爲數據庫作一個大的操做，因爲內存不足，數據庫須要將內存中的文件寫到磁盤上，這樣則有可能致使臨時文件寫的很是大，一般出現這種狀況的時候，數據庫在作大的排序操做（order by，group by），因爲內存不足，須要將數據刷寫到臨時文件中，下圖的案例中，因爲數據庫中一條order by的語句頻繁的執行，可是排序的sql沒有索引，致使了臨時文件的頻繁寫操做：

Ps.RDS已經計劃在idb中集成實例的空間診斷這個功能，幫助用戶分析實例空間的使用，診斷問題的根源。

四．實例規格：

不一樣的RDS實例規格提供了不一樣的性能指標，能夠參考RDS不一樣規格的

測試報告 。如何選擇RDS的規格，因爲該選項會直接關係你的應用是否在RDS上正常的運做起來，同時還關係成本的問題，因此深入的理解這些參數，有助於你更好的使用RDS，更低成本的使用RDS。下面來分析一下RDS規格中這3個關鍵指標：

1. 內存（mem）：內存是實例的核心指標之一，好比2400M Mem內存的實例，內存參數大小配置在實例的參數文件中，限定了實例可以使用的內存大小爲2400M。因爲內存的訪問速度遠遠大於磁盤，因此一般狀況下，內存中緩存的數據越多，數據庫的響應就越快；若是內存較小，當數據超過必定量後，就會被刷新到磁盤上，若是新的請求再次訪問該數據，就要從磁盤上把它從磁盤中讀取進內存，消耗磁盤io，這個時候數據庫響應就會變慢。
2. IOPS:剛纔提到數據從磁盤讀取到內存，或者數據從內存寫到磁盤都須要消耗io，而磁盤的io能力是有必定，好比新1型提供的iops爲150個，也就是每秒可以提供150次的隨機磁盤io操做，因此若是用戶的數據量很大，內存很小，而寫入，更新，刪除，查詢的壓力很大，因爲iops的限制，對於數據庫來講就是一條sql須要執行很長的時間才能返回結果，對於應用來講就會形成總體響應的變慢；
3. 鏈接數：鏈接數是數據庫中的一個概念，在RDS中的鏈接數是指用戶最多可以建立多少個鏈接。用戶的鏈接數使用的多少取決於用戶的鏈接類型，例如用戶使用了鏈接池管理鏈接的長鏈接應用（如java類應用），在鏈接池中配置的最大鏈接數爲100，那麼在RDS中看到的鏈接數應該爲：app服務器×100；對於短鏈接的應用而言（如php應用，C/S結構的應用），一個請求到到數據庫，就會產生一個鏈接，當請求完畢後就會釋放鏈接。當用戶使用的鏈接數超過了實例規定的鏈接數後，RDS會直接拋錯給應用，mysql：too many connections，sqlserver：Logon failed for login ‘u_xxxx’ due to trigger execution.

     能夠看到上面的3個核心指標都可以直接影響用戶使用，下圖展現了不一樣規格可以達到的QPS指標，該測試報告採用標準的sysbench oltp（讀寫混合）測試模型，能夠做爲每種實例規格的吞吐能力的參考，用戶能夠根據本身的業務壓力來選擇合適的實例規格：

五．地域選擇：

RDS的集羣主要分佈在杭州和青島兩個地域，用戶每每採用SLB+ECS+RDS的架構，因此保持着三者在同一個地域就能夠了，杭州到青島的網絡訪問延遲大概在20ms左右，因此應當避免跨地域的訪問狀況。

原文連接:http://www.tuicool.com/articles/MJzuIn