RDS最佳实践(三)—如何制定相关的流程来规范RDS的使用_MySQL

上一篇文章中,我们介绍了如何快速的把本地自建的数据库迁移入云,那是不是把数据库迁移到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 suspended

130616 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 communication

packets 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

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: order

Engine: InnoDB

Version: 10

Row_format: Compact

Rows: 5708209

Avg_row_length: 357

Data_length: 2042626048

Max_data_length: 0

Index_length: 9014607872

Data_free: 5242880

Auto_increment: NULL

Create_time: 2013-04-09 22:56:57

Update_time: NULL

Check_time: NULL

Collation: utf8_bin

Checksum: NULL

Create_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`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`)

希望这篇blog能够对你使用RDS有所帮助.