译者介绍
杨志洪，dbaplus社群联合发起人，新炬网络首席布道师，对数据库、数据管理有深入研究，合译《Oracle核心技术》《OracleExadata专家手册》。
原作者：RajeshSaluja，美国财税软件公司Intuit数据架构师，主导了Intuit数据库从本地的Oracle迁移到AmazonAuroraPostgres的全过程。
首先，本项目的目标是将本地的Oracle数据库迁移到云上的AmazonAurora数据库。
原则：
零数据丢失
零数据损坏
一、AmazonAurora数据库的优势
高性能和可扩展
相同硬件环境下，AmazonAurora的吞吐量是标准MySQL的5倍，标准PostgreSQL的3倍。
这一性能与商业数据库旗鼓相当，而成本只有后者的十分之一。可以跨3个可用区（AZ:AvailabilityZone）建最多15个低延迟的只读副本，来扩展读应用的能力和性能。
高可用和持久化
AmazonAurora提供超过4个9的可用性标准(注：一年可非计划停机52.6分钟)。在跨3个可用区内每份数据有6个副本，因此Aurora有容错及自愈功能。
Aurora持续备份数据到AmazonS3上，当发生物理存储损坏或者实例故障时能够进行透明恢复，恢复通常在30秒内完成。
高安全性
AmazonAurora为数据库提供了多个级别的安全。包括用AmazonVPC进行网络隔离，通过AMS秘钥管理服务进行数据加密，通过SSL进行加密数据传输。
一个加密了的AmazonAurora数据库实例，底层存储的数据是加密了的，自动备份、快照及集群中的副本也是加密的。
完全托管
AmazonAurora由AmazonRDS（Amazon关系数据库服务）全面管理。你不必再担心数据库的日常管理，比如硬件预置、软件补丁、安装、配置及备份。
Aurora会持续地监控数据，并自动将其备份数据库到AmazonS3，因此可以实现精细的时间点恢复策略。可以用AmazonCLoudWatch、增强监控功能监控数据库性能，还可以用PerformanceInsights帮助快速检测性能问题。
二、AmazonAurora体系结构
当我们创建一个AmazonAurora实例时，首先创建了一个数据库集群。一个数据库集群由一个或多个数据库实例组成，集群中的集群卷（clustervolume）管理所有实例的数据。
Aurora集群卷是一个虚拟的数据库存储卷，横跨多个可用区，每个可用区有数据库集群数据的一个副本。
一个Aurora数据库集群由两种类型的数据库实例组成，主实例（Primaryinstance）和副本实例(AuroraRepilca)：
主实例：支持读写操作，对集群卷（clustervolume）完成所有的数据修改。每个Aurora数据库集群有一个主实例。
副本实例：仅支持读操作。每个Aurora数据库集群最多可以为主实例添加15个副本实例。多个副本实例分担读的压力，将副本实例分散在不同的可用区同时增强了数据库的可用性。下图展示了一个Aurora数据库集群中集群卷、主实例、副本实例的关系：
三、分支的选择：MySQL和Postgres的区别
挑选合适的数据库技术是非常重要的，应用需求、可用性、安全需求决定了哪种技术更满足需要。下表罗列了MySQL和Postgres的关键区别（针对从Oracle迁移过来，选谁更合适这一需求）：
四、最终选择及采取策略
Postgres成为了最终的赢家，因为应用不能遵循MySQL的规则。MySQL要求，如果表有Primarykey或者uniquekey，那么分区表的分区列必须包含在唯一键或者主键里。另外，interval分区特性也是个考虑点，能降低运营成本。
迁移策略检查AmazonSCT工具输出的迁移评估报告，并修正报告中提及的问题项。
在AWS上创建OracleRDS，将数据从本地Oracle数据库迁移到OracleRDS。
如果应用不能接受停机割接，则在本地Oracle和云上OracleRDS之间部署Goldengate复制。
用模式转换工具（SCT，SchemaConversionTool）进行从Oracle到Aurora的模式转换。
初始数据同步前，禁用所有AmazonAurora上的外键。
对持续运行的应用，用DMS（AWSDataMigrationService）将数据从OracleRDS迁移到Postgres。
在AmazonAurora上启用所有外键。
在postgres上配置自动功能，自动清除旧的分区。
DDL/DML复制是DMS开箱即用的功能。我问支持DDL/DML复制么？当然！而且不需要再配置什么别的。
数据库性能深度分析（PerformanceInsights）也是开箱即用的功能。目前仅仅支持AmazonAurora。
删除迁移过程中的临时资源（比如复制实例、任务、endpoint及OracleRDS等），迁移工作就算完成了。
整个迁移流程基本如下图所示（从RDSOracle到AuroraPostgres都是在云上完成）：
回退策略采用DMS进行回退，或者用Goldengate也可以。
Postgres作为源端，OracleRDS作为目标端。
把已经存在的数据或者增量数据从源端迁移到目标端（取决于回退方法以及应用可以允许停机多久来做回退）。
整个迁移应该说作者写得还是有点简单了，AWS有更详细的文档，在迁移三步走的playbook里：
它对Oracle一些重要的特性与Postgres做了较详细的对比（异构数据库间的迁移都可以参考下）：
SQLPL/SQL方面：
表和索引方面：
数据库对象方面：
数据库管理方面：
我们可以看到除了交换分区和UTL_file是不支持的，其他大部分Oracle功能AuroraPostgres都满足。其实这是很正常的，PostgreSQL是对Oracle兼容性最好的开源RDBMS。
Amazon在年将它最大的数据仓库从Oracle迁移到了AmazonAurora（虽然在PrimeDay那天宕机了，但此后一直稳定运行，说明这个迁移还是很成功的）。在PrimeDay期间，这个Aurora数据库承载的业务每天处理超过万个包裹。
并且计划要在年底把所有在用的Oracle数据库都迁移到AWS自己的数据库上，说明Aurora在架构和工程上都已经可以承载大规模应用了。对于一般规模的电商应用来说，应该是小菜一碟，intuit的实践也说明了这一点。
在这篇文章的最后，有2个回复都是在赞扬Aurora。
我们在用Aurora，非常棒！我现在看不到任何用Oracle的必要性了。
在SantaClara参加AWS峰会上，一个客户分享过类似的案例。他们从Oracle迁移到了AWS，节省了大量资金。更为重要的是，响应时间从36小时缩短到30秒钟，而且易于使用，易于管理，易于操作。超酷！AWS可能会终结正在苦苦挣扎的Oracle。
要不是实名评论，我怎么都怀疑是厂家在自吹自擂。到