自从 2018 年 8 月 8 日，AWS Database Migration Service 和 AWS Schema Conversion Tool 在 AWS 中国（北京）区域和 AWS 中国（宁夏）区域推出以来，已有 3 个多月的时间，在这段时间里已经有非常多的 AWS 客户及合作伙伴，在 AWS 中国（北京）区域和 AWS 中国（宁夏）区域 试用了该服务或已正式投入生产。根据大家在使用过程中遇到的一些问题及优化建议进行了总结，并分享如下。
(一) 常见迁移环境
AWS DMS 是一项托管服务，可轻松迁移关系数据库、数据仓库、NoSQL 数据库及其他类型的数据存储。可以在本地实例之间或云与本地设置的组合之间使用 AWS DMS 将数据迁移到 AWS 云中，广泛支持将各种开源数据库、商业数据库以及托管的 RDS 作为数据迁移的源与目标，总之需要源与目标任何一端在 AWS 云端即可，AWS DMS 架构参考如下：
运行 AWS DMS 数据迁移的完整过程如下：
确定用于数据迁移的网络环境；
确定数据迁移的源和目标数据库；
创建 AWS DMS 复制实例；
配置源和目标数据库连接信息的终端节点；
创建复制任务，指定要迁移的数据表和转换规则；
迁移后的数据验证；
在 AWS DMS 数据迁移过程中，网络环境至关重要，是整个数据库迁移项目成功的关键，针对不同的迁移场景，对几种常见的网络环境说明如下：
源与目标在同一 VPC 内
源与目标在不同 VPC
通过专线或 VPN 从本地数据中心到云端
通过互联网从本地数据中心到云端
对于以上 4 类网络环境，第 1、2 类情况都是在云端，不存在网络稳定性问题，像跨帐号、跨 VPC 的都可以直接采用 VPC 的对等连接。
在实际的迁移案例中，往往大家遇到的都是第 3、4 类情况，在测试阶段大都是采用 VPN 或是互联网。由于中国互联网的环境复杂，数据量稍大点，测试过程中就可能遭遇各种莫名其妙的问题。第 3、4 类情况，如果是长期运行的 DMS CDC 持续数据迁移任务，请尽量选择专线。如果是一次性数据迁移，网络环境不稳定、数据量大，建议采用先导出 CSV 到 S3, 再将 S3 作为 DMS 的源。
(二) 常见问题及优化方法
AWS DMS 在数据库的迁移过程中复制实例都是通过 ODBC 接口与源、目标数据库通讯来实现数据的最终一致，Redshift 为提高性能采用的方法比较特殊，是先到 S3 再 COPY 到 Redshift ，常见问题及优化方法汇总：
如何设置复制实例的子网组？
子网组是复制实例驻留的地方，请参照上面 4 类网络环境去设置。如果是访问位于互联网上的数据库，建议用公有子网或带 NAT 的私有子网。如果都在云端，建议与目标数据库位于相同的子网。
为什么目标端数据库表中数据中文内容都显示成乱码或问号？
中文乱码属于常见问题，请检查源与目标端的数据库字符集是否一致。针对不同的数据库有不同的设置方法，请在迁移前优化确认此项设置。只要有中文乱码问题数据验证都无法通过。
如何正确设置源与目标的额外属性？
额外属性主要用于控制复制实例在源与目标的行为，针对不同的数据库，源与目标的额外属性内容不一，但设置方法雷同，详细请参见官方文档中心的说明，主要规则说明如下：
a) 具有多个额外属性，用分号分隔；
b) 单个属性多个值时，用逗号分隔；
如下是将 MySQL 数据库作为源，Aurora 作为目标时的额外性调置参考：
eventsPollInterval=60;initstmt=SET time_zone=’+08:00′,autocommit=1;CleanSrcMetadataOnMismatch=false
parallelLoadThreads=2;initstmt=SET FOREIGN_KEY_CHECKS=0,time_zone=’+08:00′,autocommit=0;maxFileSize=65536;CleanSrcMetadataOnMismatch=false
如何启用验证与日志记录？
在创建任务的时候选择启用验证与日志记录。
通过查询表统计数据，能看到验证状态。
启用日志记录，直接点击能到 CloudWatch 查看日志。
即使前面验证都正常，也要养成查看日志记录的习惯，只有日志里面才会详细记载 DMS 的运行过程，这是后期 DMS Troubleshooting 与 Performance Tuning 的主要信息来源。
为什么总是有一些表没数据或是迁移不成功？
请先检查日志，确认日志里面是否有主外键冲突的提示？如果有请参考额外属性禁用主、外键约束检查，如果已经设置请确认是否生效或设置正确。
为什么有些表的完整加载行比总量还多？
这种现象可能是因为重复加载导致，不稳定的网络有可能会触发 DMS 的重复加载。建议先检查日志，再找到对应的表，如果有重复加载在日志里面会有显示。尤其像 Redshift 的迁移机制很容易产生这种问题。
为什么“完整加载行”与“总量”一致，但数据验证还是未通过？
仅凭记录数是无法保证数据的一致性，AWS DMS 采用一种 HASH 算法来验证迁移后源与目标数据内容的一致性，如果记录数一致，但验证未通过，绝大多数是因为字符集与时区问题导致的字段内容不一致，设置正确的额外属性并重新加载数据。
为什么 DMS 实例运行一段时间后任务就挂起？
先通过 ping 检查 DMS 实例是否通讯正常，再检查复制实例的运行状态，确保 DMS 实例本身运行正常，最后去检查 DMS 运行日志，结合对应的时间点来看监控数据。如果这些数据都正常，再去检查任务的设置是否合理，单个任务理论上能支持 60000 张表，但这与所采用的 DMS 实例类型有关，如果换更大实例也不能解决 DMS 实例需要的资源，建议拆分成多个实例。
如何提高大型表的迁移性能？
DMS 在迁移的过程，数据导出操作会有共享锁，如果在单个任务中迁移大表，会增大 DMS 导出操作持有共享锁的时间，大型表建议根据筛选条件进行任务分解。
我应该选择什么样的迁移类型？
根据不同的业务场景，如果是可以停机的一次性数据迁移，建议选择“迁移现有数据”，如果迁移过程中要避免停机或不影响业务，建议选择“迁移现有数据并复制持续更改”，如果只是需要复制增量数据，建议选择“仅复制数据更改”。
(三) 总结及参考资源
AWS DMS 目前主要定位于数据库迁移，并支持一部分数据源的 CDC 功能，支持与其他的 AWS 服务集成，目前已经支持 S3 、CloudFormation ，可以实现更多的扩展功能。像 AWS RDS 本身并不提供 BINLOG 分析功能，可以结合 AWS DMS CDC 的功能，对要分析的源库启用 CDC 复制，并将 S3 作为目标，变更的数据都会以 CSV 格式自动复制到 S3 桶里，通过直接分析 CSV 文件，实现对数据库的日志分析。AWS DMS 不支持基于时间的任务调度，可以结合 CloudFormation 自动化与 Lambda 调度复制任务。
对于将 Amazon Aurora, Amazon Redshift 或 Amazon DynamoDB 作为目标的迁移任务，并且使用单 AZ 的 t2.micro, t2.small, t2.medium, t2.large 和 c4.large 五种实例类型，将提供 6 个月的免费使用时间用于数据迁移。
AWS DMS 除了具备数据库迁移能力外，更像是传统企业端的 CDC 增量数据库复制软件，提供企业级数据库整合、数据分发功能，并能向数据仓库提供增量数据，后期我们将期待更多的 AWS DMS 特性发布。
相关文章：
AWS DMS 详细文档
AWS DMS 分步迁移指南
AWS DMS Free 说明
AWS SCT 详细文档
作者介绍：
蒋华
AWS APN 合作伙伴解决方案架构师，主要负责 AWS (中国)合作伙伴的技术支持工作，同时致力于 AWS 云服务在国内的应用及推广，并在关系型数据库服务、存储服务、分析服务、 HA/DR 及云端应用迁移方面有着丰富的设计和实战经验。加入 AWS 之前，曾在 IBM(中国) 工作 12 年，历任数据库售前工程师、UNIX 服务器资深售前工程师及解决方案架构师，熟悉传统企业 IT 架构、私有云及混合云部署，在数据库、数据仓库、高可用容灾及企业应用架构等方面有多年实践经验。
本文转载自 AWS 技术博客。
原文链接：
https://amazonaws-china.com/cn/blogs/china/database-ten-questions/
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论