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

  • 时间:
  • 浏览:0
  • 来源:大发快3APP下载—大发时时彩登录地址

二.安全保密:

可参考:mysql主键的缺少由于备库hang

已经 文章中,你们都你们都介绍了如保快速的把本地自建的数据库迁移入云,那是就有把数据库迁移到RDS后,用户就哪几种就有前要做了?比如RDS帮你的数据库做到了高可用,在主库老出down机助于于够快速切换到备库,立刻恢复应用;每天会定时的备份数据和日志,可能老出误操作助于帮你恢复到任意时间点;可能担心黑客攻击可能sql注入漏洞,RDS助于帮助你进行sql注入的拦截;当数据库使用中老出bug时,后端有专业的源码和DBA团队帮助用户实例打上patch,让用户无后顾之忧;当实例的性能老出瓶颈的已经 ,助于于进行快速的弹性升级,保证服务的正常运行等等。

三.索引设计误区:

.禁止对无关人员提供系统登录和发布权限;

Create_options:

.自增型主键设计(int,bigint)助于于降低二级索引的空间,提升二级索引的内存命中率;

   Data_length: 20426220048

版权声明:本文内容由互联网用户自发贡献,版权归作者所有,本社区不拥有所有权,如保让承担相关法律责任。可能您发现本社区含有涉嫌抄袭的内容,欢迎发送邮件至:

 –defaults-file=’/etc/my20015.cnf’ –password=xxxxxxxx –user=’Xtrabak’ –host=’127.0.0.1′ –port=’20015′ –unbuffered –

  KEY ind_order_info_sd (sd_id,is_send,add_time),

Avg_row_length: 357

  KEY ind_order_is_send (is_send),

.全网变更前要经过线下测试,线上小规模验证后,助于全网推送;

   Check_time: NULL

   Collation: utf8_bin

1200616 00:00:58 innobackupex-1.5.1: Starting mysql with options:

1200616 00:00:58 innobackupex-1.5.1: Connected to database with mysql child process (pid=31437)

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`)

全都前要用户制定出合理的流程规范来使用RDS,比如设计开发过程中的数据库流程规范,线下测试环境与线上生产环境数据的导入导出流程规范,线上数据订正的流程规范,线上数据库操作(加在字段,加在索引)的流程规范,数据库上线下线的流程规范。

1200616 00:01:00 innobackupex-1.5.1: Starting to lock all tables…

 

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

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

进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

2013-06-16 00:01:06 [info]: ====================================== All backup finished .

在阿里巴巴数据库技术团队,即使有了非常自动化的运维平台,上述的哪几种流程制定也是开发,测试,DBA都前要遵守的,如保让可能有了上述的哪几种流程才除理了全都太多要的故障指在,大大提高了整个平台的稳定性,除此之外还制定了运维红线:

   Data_free: 52428200

  KEY ind_order_is_yushou (is_yushou),

  UNIQUE KEY order_sn (order_sn),

   Index_length: 90142007872

一.表主键的设置:自增主键后会你的最佳选用

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

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`)

   Engine: InnoDB

(`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`)

案例一:下面的这幅图片如保让myisam引擎的表可能如保让大查询堵塞了该表的如保让 更新:

  KEY ind_order_dist_type (dist_type),

一. 一个多多劲会发现可能买车人的开发人员误操作由于用户数据被误删除,着实 RDS支持恢复到任意时间点,但毕竟前要时间去恢复,会造成对用户的影响;全都线上的操作务必谨慎,前要在测试环境中完正验证助于于到线上执行,一齐前要必要的数据备份;

Max_data_length: 0

  KEY ind_user_nick (user_nick),

error log:

.主机断电,crash后Myisam表容易老出索引坏叶,前要手工repair修复索引;

  KEY ind_agency_id (agency_id),

  KEY ind_order_jhd_id (jhd_id),

.禁止未经正式审批进行查阅,变更,传播,移动线上数据;

  KEY ind_order_id (order_id),

  KEY ind_order_ck_id(ck_id ),

  KEY ind_invoice_no (invoice_no),

   Update_time: NULL

1200616 00:00:58 innobackupex-1.5.1: Continuing after ibbackup has suspended

  KEY ind_extension_id (extension_id) ,

>> log scanned up to (8679722007)

  KEY ind_user_id (user_id),

助于于就看RDS可能具备相当丰厚的自动化数据库运维的功能,用户太多太关心后端数据库的运维,已经 哪几种非常专业的DBA工作完完正全助于于交由RDS系统来完成,没人还前要用户做哪几种,是就有不前要用户干预了?答案是前要的,在日常的工单问提发现:

.重大变更(数据库停机,扩容,迁移)前要团队review;

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

.数据订正和数据提取前要经过团队leader审核通已经 助于进行操作;

一.禁止在非变更窗口执行变更:

   Rows: 5708209

2013-06-16 00:01:06 [info]: Xtrabackup error,you can get detail from Logfile.

  PRIMARY KEY (order_id),

.RDS的内存配置innodb的innodb_buffer_pool_size,Myisam的key_cache配置32k;

数据库开发规范:赶集网(国内互联网公司)的DBA 吴诗展把买车人多年的数据库mysql运维开发检验总结了—MySQL数据库开发的三十六条军,对于全都的RDS用户来说同样是很受用的,包括了:基本军规,字段军规,索引军规,SQL类军规,约定类军规,在此也很感谢他助于把多年来的经验总结分享给众多的数据库用户,在这里也在着重强调如保让 比较重要的规范:

.所有的变更前要提前4小时提交申请,进过审批助于于执行操作;

  KEY ind_shipping_id (shipping_id),

  KEY ind_order_info_lylx (lylx,order_status,is_send);

  UNIQUE KEY deal_code (deal_code),

  KEY ind_order_info_status (shipping_status),

该表的数据助于于助于 2G,如保让 索引却占用了9G

二.引擎选用:INNODB 引擎后会你的最佳选用

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

索引设计误区二:对查询的所有字段建立组合索引

.无主键的表删除,更新在row模式的主从架构,会由于备库hang住;

   Version: 10

Auto_increment: NULL

  KEY ind_order_is_separate(is_separate),

*************************** 1. row ***************************

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`)

packets  while waiting for reply to MySQL request: ‘FLUSH TABLES WITH READ LOCK;’ at /usr/bin/innobackupex-1.5.1 line 381.

   Checksum: NULL

  KEY ind_delivery_time (delivery_time) ,

  KEY ind_mobile (mobile),

误区案例一:对查询条件的每个字段建立单列索引

二.开发人员发布了如保让新功能,如保让 新功能中的根小sql句子没人加在索引,由于了全表扫描,RDS的CPU,IO达到200%,影响了整个应用的响应时间;全都新发布的任何sql都前要进过严格的审核,加在在必要的索引;

  KEY ind_order_pay_status (pay_status),

四.RDS实例可能时间到期后没人及时进行除理,由于实例被锁定可能释放,着实 最终数据助于于恢复回来,但你这人故障的指在往往令人心惊胆寒;

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

KEY `idx_plt_taobao_order_dp_id`

使用INNODB存储引擎还是Myisam存储引擎?

   Name: order

innobackupex-1.5.1: Error: mysql child process has died: ERROR 11200 (08S01) at line 7: Got an error writing communication

  KEY idx_cz_shipping_fee (cz_shipping_fee),

KEY:该表有近200个索引

.在设计表的已经 默认都加在一列无业务意义的自增id的主键:id bigint not null auto_increment;

案例二:.FEDERATED 存储引擎使用指在bug,会由于备份失败

   Row_format: Compact

  KEY ind_consignee (consignee),

SQL查询:

.自增型主键以助于插入性能的提高

   omment: 订单表

三. 开发人员在业务高峰期对表进行如保让表加在索引可能加在字段的操作(删除数据),由于该表的如保让 访问堵塞,影响前端应用;全都任何的线上操作都前要在业务的低峰期进行,生产变更前要严格控制在可允许的变更窗口内;

.自增型的主键助于于减小page的碎片,提升空间和内存的使用;

  09:44:03>  show table status like ‘order’\G; 

>> log scanned up to (8679722007)

  KEY ind_pay_id (pay_id),

.Myisam存储引擎的表备份已经 会被全局锁住,由于无法写入数据;

 and o.add_time>= ’1370246433′ and o.add_time<= ’1370332842′