Category: Database

继静态加密之后，Amazon DynamoDB 团队趁热打铁，再次为大家献上有用的功能。在 AWS re:Invent 2017 上，我们为 DynamoDB 表推出了全局表和按需备份与还原功能。今天，我们进一步推出了连续备份和时间点还原 (PITR) 功能。

对于 Amazon Aurora，您可能已有所了解。Aurora 是一种完全托管、可自动扩展到 64 TB 的数据库存储，提供与 MySQL 兼容或与 PostgreSQL 兼容的版本。创建 Aurora 数据库实例时，您可以选择所需的实例大小，并可以选择使用只读副本提高读取吞吐量。如果处理要求或查询率发生变化，您可以选择修改实例大小或根据需要更改只读副本的数目。此模型在工作负载可预测、请求速率和处理要求较高的环境中运行极佳。 在某些情况下，工作负载可能是间歇性和/或不可预知的，并且每天或每周可能有仅持续数分钟或数小时的请求高峰。限时抢购、偶发或一次性事件、在线游戏、报告工作负载 (每小时或每天)、开发/测试和新上线应用程序都具有上述特点。要分配恰好够用的容量很难；按固定价格付费又不够明智。 Amazon Aurora Serverless 发布 我们于今日推出 Amazon Aurora Serverless 预览版 (立即注册)。此新配置专为多变的工作负载设计，让您能够以秒为单位为所用的数据库资源付费。 此无服务器模型构建在处理和存储清晰分离的基础上，处理和存储清晰分离是 Aurora 架构的一部分 (有关更多信息，请参阅 Design Considerations for High-Throughput Cloud-Native Relational Databases)。您不必预先选择数据库实例大小，而是创建一个终端节点，根据需要设置所需的最小和最大容量，然后向此终端节点发出查询。终端节点是一个简单代理，它将查询路由到快速扩展的数据库资源队列。这样，即使在后台执行扩展操作，您的连接也能保持不变。扩展操作极为迅速，新资源可在 5 秒内上线。下图说明了这些功能是如何结合在一起的： 存储和处理是分开的，因此处理容量可以缩减至零 (此时，您只需支付存储费用)。我认为这一点很棒，它有可能催生随开即用的新型瞬时应用程序。基于可随时启用以处理请求的“热”资源池进行扩展 (可在数秒内完成)。新增资源基于现有的已缓存和已缓冲内容，可实现全速运行。这让您能够毫不费力地将现有 Aurora 数据库转换为无服务器模型。 基于 Aurora 容量单位计费，每个单位代表计算能力与内存的组合。以 1 秒为增量进行计量，每个新增资源最低计 1 分钟。 敬请关注 2018 年初，我将向大家介绍有关 Amazon Aurora […]

去年年底，我提到过我们向 Amazon Aurora 添加 PostgreSQL 兼容性的计划。公告发布后不久，我们推出了封闭测试版，并于今年年初发布了一个公开预览版。在测试版和预览版期间，我们收到了很多极好的反馈，我们将倾尽全力确保产品满足乃至超出大家的期望！ 现已正式发布 非常高兴告诉大家：兼容 PostgreSQL 的 Amazon Aurora 现已正式发布，您现在就可以在四个 AWS 区域 (将在更多区域发布) 使用它。它兼容 PostgreSQL 9.6.3，可自动扩展为支持高达 64 TB 的存储 (后台采用 6 路复制技术以提升性能和可用性)。 与兼容 MySQL 的 Amazon Aurora 一样，这是一个完全托管版本，非常容易设置和使用。在性能方面，吞吐量最高可达您自己运行 PostgreSQL 时的 3 倍 (可以参阅 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 了解我们如何做到这一点)。 您可以从 RDS 控制台启动兼容 PostgreSQL 的 Amazon Aurora 实例：引擎选择 […]

作者：Jeff Barr | 原文链接 今天，我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能：数据库快速克隆。利用 Aurora 的底层分布式存储引擎，您可以快速、经济地创建数据库的写入时复制克隆。 在我的职业生涯中，我经常需要花时间等待一些有代表性的数据样本，以便用于开发、试验或分析。如果我有一个 2TB 的数据库，则在执行任务之前，等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内，我也仍需花几个小时等待快照副本完成，然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。 借助 Aurora 的分布式存储引擎，我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针，存储引擎可实现数据库快速克隆。然后，当您更改源或克隆中的数据时，写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着，以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。 创建克隆所花的时间与数据库大小无关，因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠，因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群，具有所有相同的持久性保证。 接下来，我们克隆一个数据库。首先，选择一个 Aurora (MySQL) 实例，并从“Instance Actions”中选择“create-clone”。 接下来，将克隆命名为 dolly-the-sheep 并对其进行预配置。 大约 5 分 30 秒后，我的克隆已变为可用状态，然后，我开始进行一些大型架构更改，但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作，因此，与传统 MySQL 相比，架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试，则随后可以创建克隆的克隆，甚至是三次克隆，依次类推，同时我还能继续更改自己的克隆。这里需要注意的是，从 RDS […]

就在两年前 (恍如昨日)，我在我发布的帖文 Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS 中向大家推荐了 Amazon Aurora。在那个帖文中，我告诉大家 RDS 团队如何以全新、不受限的观点来看待关系数据库模型，并解释了他们如何为云端构建关系数据库。 自那之后，我们收到了一些来自客户的反馈，非常感人。客户非常喜欢 MySQL 兼容性，重视高可用性和内置加密。他们对以下事实充满期待：Aurora 围绕具有容错能力和自我修复能力的存储而构建，使他们能够从 10 GB 一直扩展到 64 TB，而无需预先配置。他们知道，Aurora 跨三个可用区创建了其数据的六个副本，并在不影响性能或可用性的情况下将数据备份到了 Amazon Simple Storage Service (S3)。随着他们不断扩展，他们知道自己可以至多创建 15 个低延迟只读副本，这些副本从公用存储中获取。要了解有关我们的客户如何在全球范围的生产环境中使用 Aurora 的详细信息，请花一些时间阅读我们的 Amazon Aurora 客户评价。 当然，客户永远在追求更多，而我们也将竭尽全力了解他们的需求并尽力满足。下面是对我们根据客户的具体反馈所做的一些近期更新的回顾： 10 月 – 从存储过程中调用 Lambda 函数。 10 月 – 从 S3 中加载数据。 9 月 […]

1.Oracle数据库的迁移方法 如何将Oracle数据库从数据中心迁移到AWS云上是DBA经常遇到的问题，迁移Oracle数据库有多种方式： (1)使用AWS DMS服务迁移 (2)使用Oracle SQL Developer迁移 (3)使用Oracle Data Pump迁移 (4)使用Oracle Export/Import迁移 (5)使用Oracle SQL Loader迁移 如果需要了解不同的迁移方法，可以参考 博客《Oracle数据库迁移到AWS云的方案》 。 2.使用Oracle Data Pump迁移 本文主要讨论使用Oracle Data Pump将Oracle数据库迁移到RDS数据库。示例数据库的信息如图。   下面是模拟在数据中心的Oracle11g源数据库中创建用户和表，并将源数据库迁移到AWS云中RDS Oracle 11g数据库的全过程。 步骤一：初始化源数据库并使用Data Pump导出 (1)使用SQL Plus登录源Oracle数据库 sqlplus / as sysdba (2)创建用户test create user test identified by welcome1; (3)为新创建用户grant权限（实际使用请给用户grant合适的权限) grant dba to test; (4)为用户test创建表 create table test.aa(id varchar(20) not null […]