【AWS征文】带你轻松迁移数据库到 AWS

现在，企业上云离不开数据库上云。然而，云上有不少数据库类型，企业该如何选择？将数据库迁移到云端，该有哪些步骤呢？不一样的业务场景下，企业该如何选择？本文将介绍 AWS 各类经常使用数据库特性，以及如何知足客户不一样业务需求，并列举数据库迁移案例为你们演示如何轻松便捷的把数据库迁移上云。

1、AWS 数据库概览

在这个互联网极其发达的时代，咱们每一个人会接收以及生产各式各样的信息，数据的重要性已经***到每一个角落，成为每一个行业发展和变革的必要元素。咱们平常使用的手机应用，好比微信、支付宝、微博等，里面的数据都是须要数据库来进行存储，不一样的应用会使用不一样类别的数据库，甚至同一个应用可能同时使用多种数据库。

应用离开了数据库就像鱼儿离开了水，因而可知数据库在当今互联网的重要性。咱们甚至能够说当今世界最宝贵的资源再也不是石油，而是数据。随着业务的快速发展，全球化业务新兴需求增长，本地传统数据库已经没法为快速发展的业务提供支持，咱们须要探索一种新的方式，把本地数据库迁移到云中，利用云中数据库的优点来解决本地数据库中遇到的瓶颈问题。

我对各家云厂商数据库种类作了一个比较，发现 AWS 为用户提供的数据库种类最为丰富，几乎把全部数据库相关的应用场景都捕捉到了。下面经过一个列表，来浏览一下 AWS 的数据库种类，其中关系型数据库最为丰富，也是目前应用使用最多的数据库。

以上这些数据库由 AWS 彻底托管，用户不用去管理底层硬件系统升级维护等相关工做，这也是推荐使用全托管数据库而非自建数据库的缘由。为了方便客户数据库迁移上云，AWS 还为客户提供了很是方便的迁移工具 DMS，帮助用户轻松经济高效的完成迁移任务。

那么面对这么多种类的数据库，尤为是一些新型数据库，咱们历来没有使用过，咱们该如何选择？咱们须要从业务场景为出发点来分析使用哪一种数据库，下面我对 AWS 数据库的使用场景作个简单的介绍，也让你们对 AWS 各类数据库的应用场景有一个大体了解。

数据库种类	应用场景
关系数据（RDS）	传统应用程序、ERP、CRM 、电子商务
键值数据（DynamoDB）	高流量 Web 应用、电子商务系统、游戏应用程序、微服务
宽列数据（Keyspaces）	用于设备维护、队列管理和路线优化的大规模工业应用程序
文档数据（DocumentDB）	内容管理、目录、用户配置文件、移动和 Web 应用程序
内存数据（ElasticCache）	缓存、会话管理、游戏排行榜、地理空间应用程序
图数据（Neptune）	欺诈检测、社交网络、推荐引擎、知识图谱
时序数据（Timestream）	IoT 应用、开发运营和工业遥测
分类帐数据（QLDB）	系统记录、供应链、注册、银行事务

初步了解 AWS 各项数据库的应用场景以后，咱们详细介绍 AWS 各项数据库特性，以及 AWS 数据库如何知足用户在各类业务场景下面的需求。

数据库家族

关系型数据库

关系型数据库是起源很是早的数据库，也是目前各类应用使用最多的数据库。咱们使用各类应用都须要注册用户，这些用户数据存放在关系型数据库里面；你在电商网站下了一个订单，订单也是存放在关系型数据库里面；咱们访问的网站，其后台数据也是存放在关系型数据库里面。因此说关系型数据库无所不在。

说到 AWS 的关系型数据库，那不得不说一下 Amazon Aurora，Aurora 是 AWS 专为云而打造的云原生数据库，它兼容 MySQL 和 PostgreSQL，它能够支撑咱们各类关系型数据库的应用场景，性能好、易扩展、安全、便于管理，Aurora 如此好用，也依托于它下面的一些特性：

• 性价比：吞吐量为标准 MySQL 的五倍，标准 PostgreSQL 的三倍，成本只有商业数据库的十分之一。
• 扩展性：基于共享存储，主从复制延迟很低，可跨三个可用区扩展至最多 15 个只读副本。
• 可用性与持久性：具备容错能力的自我修复存储；跨三个可用区创建六个数据副本；持续备份至 S3。
• 安全性：VPC 网络隔离、静态/传输数据加密、知足大多数地区合规性要求。
• 全球数据库：数据库跨越多个 AWS 地区同步复制，将数据库置于用户端，能够实现低延迟（典型延迟小于 1 秒）的本地读取和跨区域灾难恢复。
• 无服务器：能够根据工做负载自动扩容缩容，无需关心底层硬件扩展，适合业务波动的应用。

Aurora 具备不少传统数据库不具备的特性，这样让 Aurora 成为关系型数据库的首选。不过若是你不想更换数据库类型，把本地现有的数据库迁移到云中，AWS 还为用户提供 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle 等关系型数据库，客户可选择相同的数据库引擎进行迁移。而且这些数据库依托于 AWS 强大的基础设施和管理，一样安全稳定。

若是 Aurora 很是吸引你，而你如今用的是 SQL Server 或者 Oracle，那该怎么办？不用担忧，AWS 为客户提供了 Schema Conversion Tool、DMS 这两个服务，能够帮助客户评估而且转换数据库对象，很是便捷地将本地数据库迁移到 Aurora。

键值数据库

互联网发展到今天，数据表愈来愈大，有的应用要求写得快、读的快等需求。关系型数据库已经没法知足咱们的需求，所以 NoSQL 数据库也就诞生了。咱们把一些不须要关系查询，要求读写快的应用数据放置在 NoSQL 数据库里面来解决性能问题。

考虑到客户的需求，AWS 也为客户提供了自研的 NoSQL 数据库 Amazon DynamoDB，它支持键值存储，也支持文档存储，特别以键值存储为核心，面对海量数据，性能很是强悍。因其由 AWS 彻底托管，因此也是无服务器架构中的重要一员。

• 扩展性：可自动纵向扩展和缩减表，以针对容量作出调整并保持性能，提供任意级别的请求流量。

• 高性能：对于通常的请求，DynamoDB 在个位数毫秒内能够完成，并且处理请求的速度不会随着数据量的增长而减慢。
• 分布式：无中心化架构，一个表上的数据能够分布到几百台机器上。

我也在 AWS 官方渠道了解到，汇量科技是一家广告公司，他们也大量使用了 AWS 的服务，尤为是对广告点击的数据，正是采用了 DynamoDB 数据存储，能够支撑 2019 年日均广告请求量 600 亿次，峰值高达 1000 亿次。如此巨大的请求量，放在关系型数据库将没法支撑，因而可知 DynamoDB 在这种应用场景性能多么强悍。

文档数据库

JSON 数据无数不在，它是一种很是灵活的格式，你能够很方便地修改一条数据的 Schema。它是一种轻量级的数据交换格式，目前使用最普遍的 API 标准 RESTfull API，它的输出标准也是 JSON。使用 JSON 进行数据建模最符合人类语言的逻辑。以上这些使用场景，咱们都须要一种文档数据库来存储 JSON 数据，它既不是关系型数据库，也不是键值数据库。

哪些应用场景会用到文档数据库呢？由于 JSON 数据的灵活，文档数据已经***到各个领域，好比在游戏中，存储用户信息，装备积分等；在物流中，存储订单信息，订单状态；在社交中，存储用户信息以及用户发表的朋友圈信息；在视频直播中，存储用户信息和礼物信息等。

为了知足客户这些使用场景，AWS 为客户提供了 DocumentDB 数据库，见名知意，它是一个云原生的文档数据库，与 MongoDB 兼容，你能够把现有的 MongoDB 数据库经过 DMS 或 mongodump/mongorestore 等原生方式迁移上 AWS。

DocumentDB 扩展性很强，水平扩展在分钟级别，最多能够扩展到 15 个读副本；垂直扩展也在分钟级，最高扩展至 768 GiB 内存；存储能够自动扩展，最高支持 64TB。这些特性都是咱们在自建数据库很难实现的。

内存数据库

现在的应用越作越大，不少都已经开始进行分布式或者微服务架构，这时候就须要一个存储库来储存用户的会话信息，否则用户可能处于频繁的登录状态；还有应用要求提高数据查询速度，这就须要给数据库添加缓存层等。以上这些应用场景都会须要内存数据库。

那么 AWS 一样在云中为客户提供了彻底托管的内存数据库 Amazon ElastiCache，客户能够把一些热数据、会话数据、消息数据、排行数据等存放在其中，以加速数据的存取速度。它支持两种存储引擎，Memcached 和 Redis。

• 极致性能：可以支持要求最严苛且须要亚毫秒级响应时间的应用程序。
• 轻松扩展：经过使用 AWS 管理控制台或者简单的 API，用户能够根据应用须要添加或删除缓存集群中的节点。
• 安全性：支持 Amazon VPC，能够进行网络隔离。经过安全组来管理集群的访问权限。
• 高可用：可将 2 到 6 个节点纳入一个具备副本的集群，若是一个节点出于任何缘由发生故障，您不会丢失全部数据。

图数据库

关系型数据库有了，键值和内存数据库也有了，已经基本知足大部分应用的平常需求，对于 AWS 来讲，这还不够。用户还会面临性能和 schema 变动不易的问题，所以 AWS 推出了图数据库 Neptune。

使用图形数据库处理社交网络数据很是高效，Amazon Neptune 能够快速轻松地处理大量的用户配置文件和交互，从而构建社交网络应用程序。

时序数据库

顾名思义，时序数据库是和时间相关的数据库。由于不少对数据的查新都是以时间段为基础的， 适用于 IoT 和运营应用程序。所以 AWS 为用户提供了 Amazon Timestream，专门处理时序数据，目前还处于注册预览版。

分类帐数据库

分类帐数据库的使用场景也很好理解，最适合的场景是“记帐本”。“帐本”是不能被更改的，每一笔记录都不能被改动，被忠实的记录下来，以备查询。Amazon Quantum Ledger Database 就应运而生了。

这听起来和“区块链”有点关系，不过 QLDB 是有中心的，而“区块链”是去中心化的，那么你可能会问，AWS 有没有去中心化的数据库，回答是有的，那就是 Amazon Managed Blockchain。咱们很难去想 AWS 到底不存在什么数据库，用户须要的它有，用户用不到的它也有，能够说达到了“应有尽有”的程度。

迁移工具

介绍了这么多的数据库，以及各类数据库的使用场景和特性，几乎知足平常应用的全部需求，那咱们确定是想知道如何使用这些数据库，以及如何把目前本地自建的数据库迁移到云中。下面咱们将介绍 AWS 为客户提供的迁移神器 AWS Database Migration Service，以及 DMS 如何帮助客户便捷高效地把数据迁移到云中的数据库。

一样 DMS 也是彻底托管的，这让咱们把主要精力放在迁移任务上面来。DMS 支持多种数据库做为迁移的源，也支持多种数据库做为迁移的目标，从下面的表格能够详细了解支持哪些数据库：

数据迁移的源	数据迁移的目标
Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、MongoDB、DB2 LUW、Azure SQL、Amazon RDS、S3	Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、Amazon RDS、Amazon Redshift、Amazon S三、Amazon DynamoDB、Amazon Elasticsearch Service、Amazon Kinesis Data Streams、Amazon DocumentDB、Amazon Neptune、Apache Kafka

咱们能够从表格中看到各类数据库引擎，AWS DMS 支持同构数据库迁移，如 MySQL 迁移到 MySQL，也支持异构数据迁移，如 Oracle 到 MySQL，在进行异构数据库迁移的过程，AWS 还为用户提供一款工具 AWS Schema Conversion Tool，可使用 AWS SCT 将源数据库架构和大部分对象自动转换为与目标数据库兼容的格式。

对 DMS 的总结，能够简单归纳为下面几个小特性：

• 简单易用
• 最少停机时间
• 持续数据复制
• 多数据源支持
• 运行可靠

AWS DMS 能够成为复制和迁移数据库的最佳工具，它能够帮助用户将数据库工做负载迁移到 AWS 并更改数据库引擎，同时最大程度地减小停机时间。根据 AWS 的说明，使用 AWS DMS 已经进行了 20,000 个数据库到 AWS 云的迁移。因为使用该产品得到了如此普遍的成功，所以没有理由不将数据库迁移到 AWS，那么下面就开始咱们的数据库迁移之旅吧。

迁移方式

全部的数据库都有本身的备份还原工具，使用这些工具咱们能够方便的进行数据离线迁移，可是会形成较长的停机时间，主要看数据量的大小。若是须要最小的停机时间，那 DMS 是最佳选择。下面大体列举了各类迁移方式对业务的一个影响程度，能够根据本身的实际状况进行选择。

因素	离线（转储）	混合	在线（DMS）
复杂度	很是简单	复杂	中等
速度	快	中等	慢
停机时间	高	中	低

2、云上数据库迁移实践

迁移解决方案

咱们在本地数据中心有各式各样的自建数据库，若是对数据库迁移上云，咱们该如何选择云中的数据库呢，我下面简单整理了一个列表，针对不一样的场景，咱们能够选择对应的解决方案。

• 现有应用程序
  • MySQL ---> Amazon Aurora for MySQL，RDS for MySQL
  • PostgreSQL ---> Amazon Aurora for PostgreSQL，RDS for PostgreSQL
  • MariaDB ---> Amazon Aurora for MySQL，RDS for MariaDB
  • Oracle ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for Oracle
  • SQL Server ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for SQL Server
  • MongoDB ---> DocumentDB
• 新的应用程序
  • 若是不须要关系类功能 ---> Amazon DynamoDB
  • 若是须要关系类功能 ---> Amazon Aurora

• 内存存储/缓存

  • Redis ---> Amazon ElasticCache
  • Memcached ---> Amazon ElasticCache
• 时序数据
  • Amazon Timestream（注册预览版）
• 跟踪各应用程序变动、加密可验证性，具有中央可信权威
  • Amazon Quantum Ledger Database

迁移须知

数据库是任何应用程序的主要组件之一，所以咱们必须谨慎地进行迁移。您须要知道数据库的大小，数据库内部表的大小以及数据库模式。

使用 AWS DMS 将数据迁移到 AWS 很简单。首先在 AWS 环境中建立复制实例，而后 AWS DMS 链接源数据库端点和目标数据库端点。迁移开始时，AWS DMS 会建立表，加载数据并同步数据库。整个复制任务都由复制实例承担，建议建立配置比较大的复制实例。

使用 AWS DMS 执行迁移的整体流程以下：

1. 建立目标数据库。
2. 复制架构。
3. 建立 AWS DMS 复制实例。
4. 定义源数据库和目标数据库的终端节点。
5. 建立并执行迁移任务。

将 MySQL 数据迁移到 Aurora MySQL

这个案例是一个同构数据库迁移，相对来讲比较简单，迁移的方案有三种，能够直接使用mysqldump导出数据，而后再导入到 Aurora，适合数据量不大的数据库，另一种是直接把数据库的源文件复制到 S3 存储桶，可使用 Xtrabackup 备份数据库而后传到 S3 中，而后用这些文件还原到 Aurora 数据库，适合比较大量的数据，不过这两种数据库都是离线传输，须要停机迁移。

针对实时在线迁移数据库，咱们须要用到 AWS DMS，下面我将演示如何从一台 MySQL 数据库，实时迁移数据到 Aurora，对于源数据库，咱们可使用 AWS RDS，或者在 EC2 上面的自建数据库，或是其余云厂商的 MySQL 数据库，下面我选择使用在 EC2 上面自建的数据来进行演示，因此操做均在 AWS us-east-1 区域。

一、配置源数据库

源数据库咱们已经有了，你能够建立一个只读权限的临时帐户用于数据迁移，咱们这里就直接用具备读写权限的帐户演示。

二、建立 Aurora 数据库

首先咱们在 AWS 控制台中建立一个 Aurora MySQL 数据库做为咱们的目标数据库，由于不是主要介绍建立数据库，因此建立过程这里再也不演示，建立完成以后，须要记录下数据库地址，帐户密码，固然为了安全，你也能够单首创建一个用于迁移的临时帐户。

三、建立复制实例

AWS DMS 复制实例执行源和目标之间的实际数据迁移。复制实例负责整个数据的迁移，对更改的数据进行缓存，因此说大一点的实例性能更好，缩短迁移时间。打开 AWS DMS 控制台，选择建立复制实例，注意网络方面的限制，须要复制实例能够链接到两个数据库。

四、建立 MySQL 终端节点

在 AWS DMS 控制台中，在导航窗格中选择 Endpoints (终端节点)。

五、建立 Aurora 终端节点

目标终端节点会更简单一写，由于是 AWS RDS，咱们能够直接勾选。

六、建立迁移任务

迁移任务中的迁移类型咱们选择复制现有数据以及持续复制变动的数据，记得源数据库开启 binlog 日志。

在表映射选项里面，选择告知 DMS 应该迁移哪些表，迁移过程当中还能够对表名进行一些转换，咱们这里就选择彻底复制整个数据库。

七、监控迁移任务

再等待一段时间以后，咱们能够在任务详情里面看到数据迁移完成，而且目标数据库数据检查没有问题。

咱们能够看到，经过 DMS 仅仅须要简单几步就能够把数据库迁移到 AWS，而且源数据库变动数据会实时的更新到目标数据库中。

将 SQL Server 数据库迁移到 Aurora MySQL

这个案例是一个异构数据库迁移，咱们会用到 AWS SCT 进行 Schema 转换，AWS DMS 支持从 RDS 迁移到 RDS，因此此次的源数据库 SQL Server 是 AWS RDS for SQL Server（Enterprise Edition）。

Schema 转换

一、在本地计算机安装 AWS SCT

须要在本身的电脑上面安装 AWS SCT 工具，以及链接 SQL Server 的 JDBC 驱动和 Aurora MySQL 的 JDBC 驱动。

驱动下载地址参照官方文档 https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.JDBCDrivers

而后启动 SCT，配置一下刚刚下载的 JDBC 驱动。

二、建立迁移项目

打开 AWS SCT，选择建立一个新项目，选择源和目标数据引擎。

分别链接 SQL Server 和 AWS Aurora 数据库。

勾选咱们要迁移的数据库，右键选择 Create report。

查看报告，看看有没有问题，若是没有问题，咱们就能够直接进行转换了。

我这边遇到一个存储过程 MySQL 不支持，我这边忽略掉，比较懂数据库的人员能够进行修正。

三、Schema 转换

问题处理掉以后，咱们就能够进行 Schema 转换了，和前面同样，右键数据库，选择 Convert schema。

执行以后，很快咱们在目标数据库看到了转换的 Schema。

数据迁移

对于 SQL Server 的数据迁移方式，咱们选择一次性迁移，不进行持续复制，持续复制配置过程稍微复杂一些，须要对源数据库进行一些配置，须要持续复制的用户，能够参照 AWS 官方文档配置。

一、建立复制实例

打开 DMS 控制台，建立复制实例，一样注意网络状况，复制实例须要连接源和目标数据库。

二、建立 AWS DMS 源和目标终端节点

建立完终端节点以后，首先运行一下测试，能够链接成功便可。

三、建立迁移任务

能够按照我下面的表格选择来配置迁移任务。

Parameter	Value
Task identifier	AuroraMigrationTask
Replication instance	replication-server
Source database endpoint	sqlserver
Target database endpoint	dst-mysql-instance-1
Migration type	Migrate existing data
Start task on create	Checked
Target table preparation mode	Do nothing
Include LOB columns in replication	Limited LOB mode
Max LOB size (KB)	32
Enable validation	Unchecked
Enable CloudWatch logs	Checked

在表映射方面，咱们能够这样设定，就不进行表名的转换了，而后建立任务便可。

Parameter	Value
Schema	Tecno
Table name	%
Action	Include

四、检查目标库数据

能够看到，迁移任务完成，数据也都转移过来了。

至此咱们完成了异构数据库迁移，整个过程会比同构数据库迁移麻烦一些，不过总体也是比较简单了。DMS 彻底托管、按量付费、图形界面操做，是数据库上云的利器，推荐你们使用 DMS 对数据库迁移上云。

3、总结

AWS 数据库优点

在众多的云厂商中，咱们为何选择 AWS 数据库服务，AWS 还有哪些独特的优点呢？我主要总结如下几点：

成本优点

使用自建数据，企业首先须要支付一笔资金购买服务器，一些商业数据库的受权，须要再次支付一笔费用。若是迁移到 AWS 的自研数据库，客户没必要再支付高昂的商业数据库受权，也没必要再去花费大量资金去购买服务器，在云中，客户只须要按量付费，所以不少企业因为把数据库迁移到 AWS 而节省巨大费用支出。

从最近的 AWS 公告中，看到 AWS 帮助三星把数据从商业数据库 Oracle 迁移到了 Aurora，为三星每个月的数据库成本下降了 44%，并让三星的数据库运行更加稳定。

彻底托管

以上所说的几种数据库都是 AWS 彻底托管的数据库，彻底托管意味着零运维。首先客户不须要去维护硬件的生命周期、系统的补丁更新、高可用的部署、备份等。若是须要对数据库扩展，也只需点几下鼠标而已，非让方便，让 DBA 从复杂的数据库运维中解脱出来，专一于数据库性能调优。

全球优点

过去咱们须要借助很是复杂的技术手段，花费大量的成本、甚至牺牲必定的可用性，才能实现快速、稳定、安全的跨区域的数据复制，如今只要在 AWS 云中轻轻点几下鼠标便可完成。

AWS 云现已在全球 24 个地理区域内运营着 77 个可用区，180个边缘站点等，为 AWS 相应全球数据库提供了基础保障。依托于 AWS 强大的基础设施，目前已经有三款数据库支持全球同步，延迟一般不超过 1 秒，能够知足目前大部分应用的需求。

对于关系型数据库的全球同步需求，Amazon Aurora Global Database 可以容许用户轻松实现跨区域的数据库部署，让用户轻松在区域之间复制数据和解决更新冲突，从而更加专一于应用程序的业务逻辑。

AWS 还提供了 Amazon DynamoDB Global Tables。它基于 DynamoDB 的全球覆盖范围构建，具备多区域、多主表的特性，可以让全局分布式应用程序实现快速的本地读写性能，为用户提供一个彻底托管的、多区域、多主的 Key-Value 类型数据库。

针对缓存数据库，在众多组织都在利用 Redis 为全球用户提供低延迟访问的背景下，AWS 为更好知足客户的需求，AWS 推出了 Amazon ElastiCache Global Datastore for Redis 全球缓存数据库，为用户提供数据跨区域复制，能够在一个区域写入数据，同时在其余区域读取数据，使缓存的数据更接近用户，减小网络延迟，并提升应用程序的响应能力。

心得与建议

固然，数据库迁移是一个庞大而复杂的工程，尤为将数据库迁移上公有云，除了数据库知识更须要了解公有云上网络，存储，虚拟化等一系列知识。可是，咱们不该该仅仅将数据库上云看作一个复杂的任务，更应该把它当作一个优化咱们数据库的契机，那么上云过程当中有哪些注意事项和建议呢？

对于一些容许停机的应用，这部分数据咱们推荐使用离线迁移，整个操做比较简单，速度快，不容易出问题。

若是业务须要在线迁移，那么推荐使用 DMS 进行迁移，须要注意的是，在数据库切换以前先停掉源数据库写入，带数据彻底同步到目标数据库以后进行数据库切换。

若是迁移的数据量比较大，建议选择配置比较大的复制实例，这样能够加速咱们的复制速度。

若是您想要转换数据库引擎，在使用 SCT 进行 Schema 转换的时候可能会遇到一些目标数据库不支持的地方，请先联系 DBA 人员，对这些地方进行更改，知足以后再进行转换。