上一篇文章中,我們介紹了如何快速的把本地自建的數據庫遷移入云,那是不是把數據庫遷移到RDS后，用戶就什么都不需要做了？比如RDS幫你的數據庫做到了高可用，在主庫出現down機后能夠快速切換到備庫，立刻恢復應用；每天會定時的備份數據和日志，如果出現誤操作能夠幫你恢復到任意時間點；如果擔心黑客攻擊或者sql注入漏洞，RDS能夠幫助你進行sql注入的攔截；當數據庫使用中出現bug時，后端有專業的源碼和DBA團隊幫助用戶實例打上patch，讓用戶無后顧之憂；當實例的性能出現瓶頸的時候，可以進行快速的彈性升級，保證服務的正常運行等等。

可以看到RDS已經具備相當豐富的自動化數據庫運維的功能，用戶不用太關心后端數據庫的運維，以前這些非常專業的DBA工作完完全全可以交由RDS系統來完成，那么還需要用戶做什么，是不是不需要用戶干預了？答案是需要的，在日常的工單問題發現：

一． 經常會發現由于自己的開發人員誤操作導致用戶數據被誤刪除，雖然RDS支持恢復到任意時間點，但畢竟需要時間去恢復，會造成對用戶的影響；所以線上的操作務必謹慎，必須在測試環境中完全驗證后才能到線上執行，同時需要必要的數據備份；

二．開發人員發布了一個新功能，但是新功能中的一條sql語句沒有添加索引，導致了全表掃描，RDS的CPU，IO達到100%，影響了整個應用的響應時間；所以新發布的任何sql都必須進過嚴格的審核，添加上必要的索引；

三． 開發人員在業務高峰期對表進行一個表添加索引或者添加字段的操作（刪除數據），導致該表的其他訪問堵塞，影響前端應用；所以任何的線上操作都需要在業務的低峰期進行，生產變更必須嚴格控制在可允許的變更窗口內；

四．RDS實例由于時間到期后沒有及時進行處理，導致實例被鎖定或者釋放，雖然最終數據可以恢復回來，但這種故障的發生往往令人心驚膽寒；

所以需要用戶制定出合理的流程規范來使用RDS，比如設計開發過程中的數據庫流程規范，線下測試環境與線上生產環境數據的導入導出流程規范，線上數據訂正的流程規范，線上數據庫操作（添加字段，添加索引）的流程規范，數據庫上線下線的流程規范。

在阿里巴巴數據庫技術團隊，即使有了非常自動化的運維平臺，上述的這些流程制定也是開發，測試，DBA都必須遵守的，就是因為有了上述的這些流程才避免了很多不必要的故障發生，大大提高了整個平臺的穩定性，除此之外還制定了運維紅線：

一．禁止在非變更窗口執行變更：

.所有的變更必須提前4小時提交申請，進過審批后才能執行操作；

.全網變更必須經過線下測試，線上小規模驗證后，才能全網推送；

.重大變更（數據庫停機，擴容，遷移）必須團隊review；

.數據訂正和數據提取必須經過團隊leader審核通過后才能進行操作；

二．安全保密：

.禁止未經正式審批進行查閱，變更，傳播，移動線上數據；

.禁止對無關人員提供系統登錄和發布權限；

數據庫開發規范：趕集網（國內互聯網公司）的DBA 吳詩展把自己多年的數據庫mysql運維開發檢驗總結了—MySQL數據庫開發的三十六條軍,對于很多的RDS用戶來說同樣是很受用的，包括了：基本軍規，字段軍規，索引軍規，SQL類軍規，約定類軍規，在此也很感謝他能夠把多年來的經驗總結分享給眾多的數據庫用戶，在這里也在著重強調一些比較重要的規范：

一．表主鍵的設置：自增主鍵是你的最佳選擇

.在設計表的時候默認都添加一列無業務意義的自增id的主鍵：id bigint not null auto_increment；

.自增型主鍵以利于插入性能的提高

.自增型主鍵設計(int,bigint)可以降低二級索引的空間，提升二級索引的內存命中率；

.自增型的主鍵可以減小page的碎片，提升空間和內存的使用；

.無主鍵的表刪除，更新在row模式的主從架構，會導致備庫hang住；

可參考：mysql主鍵的缺少導致備庫hang

二.引擎選擇：INNODB 引擎是你的最佳選擇

使用INNODB存儲引擎還是Myisam存儲引擎？

.RDS的內存配置innodb的innodb_buffer_pool_size,Myisam的key_cache配置32k；

.主機斷電，crash后Myisam表容易出現索引壞葉，需要手工repair修復索引；

.Myisam存儲引擎的表備份時候會被全局鎖住，導致無法寫入數據；

案例一:下面的這幅圖片就是myisam引擎的表由于一個大查詢堵塞了該表的其他更新：

案例二：.FEDERATED 存儲引擎使用存在bug，會導致備份失敗

error log:>> log scanned up to (867972807)130616 00:00:58 innobackupex-1.5.1: Continuing after ibbackup has suspended130616 00:00:58 innobackupex-1.5.1: Starting mysql with options:–defaults-file=’/etc/my3015.cnf’ –password=xxxxxxxx –user=’Xtrabak’ –host=’127.0.0.1′ –port=’3015′ –unbuffered —130616 00:00:58 innobackupex-1.5.1: Connected to database with mysql child process (pid=31437)130616 00:01:00 innobackupex-1.5.1: Starting to lock all tables…>> log scanned up to (867972807)innobackupex-1.5.1: Error: mysql child process has died: ERROR 1160 (08S01) at line 7: Got an error writing communicationpackets while waiting for reply to MySQL request: ‘FLUSH TABLES WITH READ LOCK;’ at /usr/bin/innobackupex-1.5.1 line 381.2013-06-16 00:01:06 [info]: Xtrabackup error,you can get detail from Logfile.2013-06-16 00:01:06 [info]: ====================================== All backup finished .

三.索引設計誤區:

誤區案例一：對查詢條件的每個字段建立單列索引

SQL查詢：

SELECT count(*) FROM order o? WHERE?? is_send=0? AND

?o.order_status in (0,1) AND o.shipping_status = 0 AND

??????? o.is_separate > 0? and o.is_yushou=0 and o.sd_id=23

?and o.add_time>= ‘1370246433’ and o.add_time<= ‘1370332842’

?and o.jhd_id=0 group by o.order_id;

KEY：該表有近30個索引

PRIMARY KEY (order_id),UNIQUE KEY order_sn (order_sn),UNIQUE KEY deal_code (deal_code),KEY ind_user_id (user_id),KEY ind_shipping_id (shipping_id),KEY ind_pay_id (pay_id),KEY ind_agency_id (agency_id),KEY ind_extension_id (extension_id) ,KEY ind_order_id (order_id),KEY ind_delivery_time (delivery_time) ,KEY ind_invoice_no (invoice_no),KEY ind_user_nick (user_nick),KEY idx_cz_shipping_fee (cz_shipping_fee),KEY ind_mobile (mobile),KEY ind_order_info_sd (sd_id,is_send,add_time),KEY ind_order_info_status (shipping_status),KEY ind_order_pay_status (pay_status),KEY ind_order_is_yushou (is_yushou),KEY ind_order_dist_type (dist_type),KEY ind_order_jhd_id (jhd_id),KEY ind_order_is_send (is_send),KEY ind_order_ck_id(ck_id ),KEY ind_order_is_separate(is_separate),KEY ind_consignee (consignee),KEY ind_order_info_lylx (lylx,order_status,is_send);
索引設計誤區二：對查詢的所有字段建立組合索引
09:44:03> show table status like ‘order’\G; *************************** 1. row ***************************Name: orderEngine: InnoDBVersion: 10Row_format: CompactRows: 5708209Avg_row_length: 357Data_length: 2042626048Max_data_length: 0Index_length: 9014607872Data_free: 5242880Auto_increment: NULLCreate_time: 2013-04-09 22:56:57Update_time: NULLCheck_time: NULLCollation: utf8_binChecksum: NULLCreate_options:omment: 訂單表該表的數據只有2G，但是索引卻占用了9個G：

KEY `idx_plt_taobao_order_dp_id`(`dp_id`,`customerno`,`created`,`endtime`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`ccms_order_status`)KEY `idx_plt_taobao_order_created` (`created`,`customerno`,`endtime`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`)KEY `idx_plt_taobao_order_endtime` (`endtime`,`customerno`,`created`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`)KEY `idx_plt_taobao_order_pay_time` (`pay_time`,`customerno`,`created`,`endtime`,`modified`,`consign_time`,`payment`

希望這篇blog能夠對你使用RDS有所幫助.

總結

以上是生活随笔為你收集整理的RDS最佳实践(三)—如何制定相关的流程来规范RDS的使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。