阿里RDS高可用性的保障原理

    对于在进行网站的高可用性应用架构构建时， 数据库应该是最底层、最稳定的组件之一。而主备设计时最流行，最有效的方式。

    阿里的RDS 采用主备复制架构，用户购买一个实例，RDS都会提供一个性能对等的备库用于保证高可用。 高可用性组件（AURORA）会每3秒检查主库(Master)状态，当发现 Master 出现Down机时可以将用户的SQL请求快速转移到备库(Slave)上面。

     在这样的架构设计下， RDS需要保证主备数据一致性并且延时不超过10秒，以快速完成主备切换；否则，RDS会保证一致性而牺牲可用性，必须等待数据同步一致再进行切换；所以主备延时会直接影响服务的高可用性。

     MySQL复制模式可以通过参数：BINLOG_FORMAT进行配置 ；在MySQL5.1以前，MySQL默认采用 Statement 模式进行数据复制，这种模式下有可能会让主备数据产生不一致情况，比如使用UUID等函数；MySQL在5.1版本以后，提供了基于ROW 模式的复制模式，从而大大提高了数据复制的可靠性；但这种模式在以下场景下会让备库的数据延时很大；
1) 存在没有主键的表，导致备库应用每个Event 都需要全表扫描 ;
2) 主库执行了大表DDL 或大事务，导致备库也要相同时间执行完 ;
RDS在实际的运行过程中发现，99%以上的主备延时，都是因为用户在建表的时候没有指定主键；

但要求所有用户加上主键按，也根本不太现实。云平台自身要解决这些问题，而用户不应该关注，最好让mysql底层处理对用户透明。

 最终阿里RDS高可用的最终方案为：

1 打开RDS 特有的参数implict_primary_key，让隐式主键功能生效 ；
2 当用户建表（CREATE TABLE）时，判断表结构
2.1 如果表上有主键，则pass
2.2 如果表上没有主键，有唯一键，则把唯一键放在索引的第一个位置，可以利用二级索引补丁 ；
2.3 如果表上没有主键，也没有唯一键，则为用户建立一个特定名称的自增主键 ；
3 当用户修改表结构（ALTER TABLE）时，判断新表结构
3.1 如果用户自己添加了主键或唯一键，则删除系统添加的主键
3.2 如果用户删除了原有的主键和唯一键，则为用户建立一个特定名称的自增主键
4 用户做DML操作时，屏蔽这个隐式主键的存在
4.1 INSERT INTO table VALUES (…)，用户不需要在VALUES中填写主键的值，系统会自动填充NULL，从而在写入数据库时自动填入自增值
4.2 SELECT * FROM table，行数据返回给用户前，自动过滤了隐式主键列
4.3 LOAD DATA INFILE，用户不会感知到表中存在主键，系统会自动填充NULL来使用自增主键值
4.4 SHOW CREATE TABLE/SHOW COLUMNS等SHOW语句，生成结构语句时自动过滤隐式主键列，用户不会看到有主键列
5 对于系统用户（root）需要查看真实情况的，提供show_ipk_info参数，SET show_ipk_info=1，则可以查看隐式主键，不会进行任何隐藏操作
6 如果implict_primary_key参数关闭，则隐式主键功能不再发挥作用，即当用户进行DDL操作时，如果原来表上有隐式主键，则会趁用户DDL之机一起删除。但是原有的没有删除的隐式主键列并不会显示给用户，会一直隐藏。