Amazon RDS介绍 （二）

上一章，对Amazon RDS以及RDS提供的主要服务做了个简单的介绍，这一章将主要描述写 Amazon RDS所提供的主要功能特点， 就是有了这些功能，所以Amazon RDS才有上一章所描述饿服务特点.

Amazon RDS 提供的一些功能

监控分析：一般关系型数据库运行过程中，我们常常需要监控数据库以及对于服务器的一些状态，得到一些监控数据，从而来衡量数据库的稳定性以及数据库设计和架构的合理性。 前面说了，RDS是一些建立在关系型数据库上的服务，项目里RDS就是当做关系型数据库来用的，所以，我们也需要对RDS进行监控。目前，Amazon提供了两种监控RDS的方式： 一种是RDS的控制台，它自动监控收集一些数据库服务器以及I/O的数据信息，还有一种就是使用Amazon的Cloudwatch服务。注意，目前，对RDS监控的粒度还是比较粗的，仅仅获得一些如 存储、I内存的使用情况，I/O的的请求情况以及当前的连接数等信息，如果想获得一些更加详细的信息，目前这两种形式的监控都还未做到，比如，我想知道哪些SQL执行特别慢，目前没法知道.

软件自动级升： RDS是建立在关系型数据库上的一种服务，它的原型还是关系型数据库，如mysql、oracle以及SQL server等，然而，随着发展，这些关系型数据库会根据业界的需要进行升级的，提供一些更加方便高效的功能供大家使用。如果这样，为了根据业界的发展，RDS也需要升级底层数据库，而这个升级打包的过程则不需要你操心，完全有RDS的管理程序自动帮你升级。当然，你可以配置不升级。

自动备份：RDS的一个非常好的功能。就是说，创建DB Instance时，你可以通过配置，使用RDS自动备份的功能，这样，RDS会自动帮你对数据库数据以及事务日志进行备份，如果有一天，你认为数据库数据出现异常了，就可以恢复数据库里的数据到备份文件保留期限里的任何时间点，很方便吧，节省了不少DBA工作。但是，使用数据库自动备份功能时，你需要知道备份功能的几个特点：

1. 自动备份产生的文件，包括数据文件和日志文件，你是不能得到和访问的。

2. 自动备份产生的这些文件，RDS会帮你保存，但是，会有一定的保存期限的，到期RDS会删除这些文件，目前最长只能保存35天。

3. 根据第2点，如果你使用自动备份功能，假如你设置的备份文件保留期限是35天，如果你想恢复到35天前的数据，是做不到的。

数据库快照（DB Snapshots): 数据库快照也是一种类似于备份的功能。你可以给你的数据库实例照一个快照，这样，这些数据都会有个快照备份，你可以通过这个快照备份，恢复数据到找快照时的这个时间点。你照快照产生的文件，RDS是不会自动删除的，但是你可以手动删除这些快照。 通过上面描述，大家应该知道，数据快照也可以作为备份的一种方式，所以在使用RDS时， 将RDS的自动备份机制和快照备份结合起来用，是非常不错的选择。

Provisioned IOPS:首先解释下IOPS，IOPS即使 I/O per second,中文意思即使每秒I/O请求次数。RDS提供这个功能，主要是方便那些对 随机读写有比较高的要求的用户。申请 DB Instance时，配置了 Provisioned IOPS功能，数据的读写性能将会大大的提升。IOPS的申请大小与 存储的大小时有一定的比例的，目前是10:1, 也就是说，你想要申请1000 IOPS，那你至少需要申请有100GB的存储。随便说下我自己的看法，我认为这个IOPS还蛮贵的，具体可以官方定价，呵呵。

RDS的副本（Replication)功能：为了增强数据的有效性以及防止出现意想不到的宕机时，数据库服务还能正常运行， RDS提供了数据库副本（replication）功能(有点经验的人应该都知道，在企业应用中，只要是设计优美的系统，都会存在一个数据库replication，防止数据库挂掉后，使用副本来提供关系数据库服务）。 RDS中，根据应用目的的不同，提供了两种形式的副本：

Multi-AZ(多地区部署）：如果你在申请一个DB Instance时，选用了Multi-AZ功能，RDS不仅为你在指定region（区域）建立一个DB Instance（暂且称主Instance吧），还会在其他地区将一个一模一样的 DB Instance，作为副本。当你在实际应用中往主Instance写数据时，同时会往副本Instance里写同样的数据, 是同步进行的，也就是说，两个写都是在同一个事务里。 所以，使用Multi-AZ,对写的性能还是有一定的影响的。 还有一点，请注意，就是这个 副本只能是在 主Instance挂掉时，升级为主副本，继续主副本的工作，在升级主副本之前，客户端是不能对它直接进行读写操作的。

Read Replication(可读副本）：前面说了，Multi-AZ产生的副本是不能为客户端进行读写操作的，也就说，它根本就不能分担一点数据库的读写压力，如果这样，但数据库的读非常频繁，数据库承受不了时，怎么办呢？ RDS提供的可读副本就是来解决这个问题的，如果在申请 DB Instance时，选用了可读副本这个功能，在创建Instance时，它也会产生一个 副本，这个副本是能接收客户端的读请求，然后返回读结果给客户端的，所以，在一定程度上，它完全能减轻 主Instance的负载压力。 这里，多说一点，主DB Instance的数据和可读副本里的数据时异步同步的，即每隔一段时间，可读副本会去主DB Instance里同步下最新数据，并不是实时的。

可读副本是RDS的一个非常重要且有用的功能，在这，我不得不罗嗦一下。目前，RDS提供了可以让你手动将可读副本升级为主DB Instance的功能，这个有什么作用呢？想想，当你在应用中，突然你要做一些非常消耗时间和数据库资源的操作时（如alter某个表，对该表添加部分字段等），而你不想停主DB Instance或影响 主DB Instance提供的服务质量时，此时你完全可以先对 可读副本进行操作处理，操作完成后，然后手动将可读副本升级为主DB Instance， 是不是很方便？ 呵呵！

版权声明：本文为博主原创文章，未经博主允许不得转载。