如何把数据迁移到云计算

英方云迁移解决方案提供了包括评估和分析、方案设计、环境准备、迁移实施、测试验证和系统割接的6个阶段，14道工序，和包括i2Move在内的3个迁移工具。

评估和分析：

确定迁移范围和目标，结合系统需求调研表，涵盖业务系统信息（业务名称、业务系统、业务分类、使用状态、对接系统等）主机信息（部署架构、IP地址、内外网访问情况、系统重要程度、可允许的宕机时间和最佳迁移 *** 作建议时间、中间件等） *** 作系统信息（CPU、内存、磁盘容量、OS版本等）数据库信息（数据名称、数据库类型、版本、高可用、数据量、备份策略等）；

方案设计：

根据评估的分析报告，设计迁移的实施方案，涵盖迁移场景的分类、特殊迁移场景、迁移方案、实施步骤、预知的迁移挑战和风险、应对方案，并针对客户和合作方提供迁移前的分工计划表以及培训计划等；

环境准备：

迁移目标的基础资源准备，包括计算、存储、网络、数据库环境、新账号、密码、待迁移系统管理员权限设置、迁出和迁移资源对应表，以及迁移软件客户端安装；

迁移实施：

系统迁移信息配置，数据库迁移、服务器迁移、服务器集群迁移，启动迁移任务和进度观察；

测试验证：

迁移后的系统稳定性、数据一致性、完整性等验证；

系统割接：

建立切割计划表，确定各个业务系统的切割时间窗口，进行业务验证，确定是否进行执行回退方案；

首先，暂停SQL2000数据库，将MDF和LDF文件备份。

这些文件复制到新机器，尝试直接附加，如果两个SQL版本一致，就这个方法最直接。但如果失败，尝试下面几个方法。

一般来说，不同SQL版本迁移数据，推荐使用两种方法进行转换：

1·使用数据库备份还原，在2000中备份成bak文件，到新系统中还原，这个方法的成功率比直接附加大的多，但如果数据库中存在特殊性不兼容的结构，此方法也可能失败，这时候使用第二种方法；

2·在2000中对数据库导出完整脚本（sql文件），在新系统中创建一个空库，执行该脚本。并使用DTS导入数据。

我们公司最近决定将数据迁移到亚马逊云科技，打算使用Amazon Database Migration Service这项服务。源数据库在迁移过程中可继续正常运行，从而最大程度地减少依赖该数据库的应用程序的停机时间。这项服务的使用案例还有同构数据库迁移、异构数据库迁移、开发和测试、数据库整合和连续数据库复制。

caching_sha2_password认证插件提供更多的密码加密方式，并且在加密方面具有更好的表现，目前MySQL 80选用caching_sha2_password作为默认的认证插件，MySQL 57的认证插件是MySQL_native_password。如果客户端版本过低，会造成无法识别MySQL 80的加密认证方式，最终导致连接问题。

MySQL存储引擎现在负责提供自己的分区处理程序，而MySQL服务器不再提供通用分区支持，InnoDB和NDB是唯一提供MySQL 80支持的本地分区处理程序的存储引擎。 如果分区表用的是别的存储引擎，存储引擎必须进行修改。要么将其转换为InnoDB或NDB，要么删除其分区。通过MySQLdump从57获取的备份文件，在导入到80环境前，需要确保创建分区表语句中指定的存储引擎必须支持分区，否则会报错。

MySQL 80的默认字符集utf8mb4，可能会导致之前数据的字符集跟新建对象的字符集不一致，为了避免新旧对象字符集不一致的情况，可以在配置文件将字符集和校验规则设置为旧版本的字符集和校验规则。

MySQL 80启动使用的lower_case_table_names值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。

< lower_case_table_names >

>

要避免MySQL 80上的启动失败，MySQL配置文件中的sql_mode系统变量不能包含NO_AUTO_CREATE_USER。

从MySQL 5724和MySQL 8013开始，MySQLdump从存储程序定义中删除了NO_AUTO_CREATE_USER。必须手动修改使用早期版本的MySQLdump创建的转储文件，以删除NO_AUTO_CREATE_USER。

在MySQL 8011中，删除了这些不推荐使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。从57到80的复制场景中，如果语句使用到废弃的SQL Mode会导致复制异常。

在执行到MySQL 803或更高版本的in-place升级时，BACKUP_ADMIN权限自动授予具有RELOAD权限的用户。

本文对MySQL 57到MySQL 80的升级过程中出现部分易出现问题进行整理：升级对MySQL版本的要求、升级都做了哪些内容、数据库升级做了哪些步骤以及注意事项，希望对大家版本升级有帮助。

云服务器数据转移大概需要多长时间呢？

互联网时代，网络业务部署，有时候可能会因为一些原因，需要更换新服务器，换新服务器需要转移数据，其中需要考虑的包括应用程序对象、需实现的功能、复杂程度及适配的原生环境等问题，那么云服务器数据转移大概需要多久呢？



一、使用原应用程序

不少企业仅仅希望将应用程序转移至云端，而不是修改，这种转移更为简单也更为节省时间，但企业将无法使用云端所拥有的功能，如果是这种方式的转移，并且你的数据量不大，那么只需要两到三个开发人员和数据库管理员大约花费两到三天时间进行转移即可，但如果数据量足够庞大，那么就很难保证时间了。

二、重构应用程序

如果需要重构并改进应用程序使其符合云原生特征，那么将和使用原程序会有很大的不同。你需要考虑有多少比例的应用程序将会被重构以及重构的复杂性。

一般来说，比例越高、越复杂，所需要的时间越长，按照常用的应用程序标准，重构10%需要一个星期，重构20%需要两个星期，以此类推。

当然，如果企业愿意投入更多的人力和资金，将会缩短相应的时间，但成本也会随着上升。

总的来说，服务器数据转移的时间取决于应用程序是否重构，及重构的比例及复杂性，当然也会受到其他方面的影响，包括应用程序的设计、技术问题及数据库类型等。

数据转换与迁移通常包括多项工作：旧系统数据字典整理、旧系统数据质量分析、新系统数据字典整理、新旧系统数据差异分析、建立新旧系统数据之问的映射关系、开发部署数据转换与迁移程序、制定数据转换与迁移过程中的应急方案、实施旧系统数据到新系统的转换与迁移工作、检查转换与迁移后数据的完整性与正确性。

数据转换与迁移的过程大致可以分为抽取、转换、装载三个步骤。数据抽取、转换是根据新旧系统数据库的映射关系进行的，而数据差异分析是建立映射关系的前提，这其中还包括对代码数据的差异分析。转换步骤一般还要包含数据清洗的过程，数据清洗主要是针对源数据库中，对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗 *** 作；在清洗之前需要进行数据质量分析，以找出存在问题的数据，否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。

对数据的检查包括以下6个方面。

(1)数据格式检查。检查数据的格式是否一致和可用，目标数据要求为number型。

(2)数据长度检查。检查数据的有效长度，对于char类型的字段转换到varchar类型中，需要特别关注。

(3)区间范围检查。检查数据是否包含在定义的最大值和最小值的区间中。例如年龄为300或录入日期为4000—1—1显然有问题。

(4)空值、默认值检查。检查新旧系统定义的空值、默认值是否相同，不同数据库系统对空值的定义可能不同，需要特别关注。

(5)完整性检查。检查数据的关联完整性。如记录引用的代码值是否存在，特别需要注意的是有些系统在使用一段时间后，为了提高效率而去掉了外键约束。

(6)一致性检查。检查逻辑上是否存在违反一致性的数据，特别是存在分别提交 *** 作的系统。

以上就是关于如何把数据迁移到云计算全部的内容，包括:如何把数据迁移到云计算、SQL数据迁移问题(数据库迁移的两种方法)、亚马逊云科技都是怎么帮助企业快速实现数据库迁移的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！