我的书签
添加书签
移除书签摘要
至今为止我们完成了SQL Server备份还原专题系列六篇月报分享：三种常见的数据库备份、备份策略的制定、查找备份链、数据库的三种恢复模式与备份之间的关系、利用文件组实现冷热数据隔离备份方案以及如何监控备份还原进度，本期我们分享阿里云是如何基于SQL Server备份还原理论来设计RDS SQL自动化迁移上云方案的。
适用场景
RDS数据库迁移上云是指将用户线下数据库搬迁到阿里云RDS上并完成应用切换到RDS上的工作过程。数据库迁移上云的重点和难点在于：如何保证用户数据库的完整性的同时，还要保证用户应用停机切换时间足够短（起码要达到分钟级）。通常使用的方法有逻辑迁移和物理迁移两种。
逻辑迁移
逻辑迁移，是指将用户线下数据库对象和数据转化为DDL和DML语句，然后在RDS上执行的迁移上云方式。这些数据库的对象包含但不仅限于：
表：数据库的表对象，是数据库存储数据的单元。如果表与表之间有建立主、外键关系，在表对象创建之前，必须找出多表之间的主、外键关系，先建立主表，再建立外表。
约束：表与表之间的主、外键约束；默认约束；唯一约束；Check约束等。
视图：视图之间很可能存在引用关系，必须先建立被引用的视图，然后再建立引用视图。
函数：函数之间也可能存在相互引用关系。
存储过程：创建存储过程不需要严格按照引用关系来创建，但很有可能存在跨库访问的情况。
同义词：同义词类似于对象别名，这个是很多人容易忽略的地方。
逻辑迁移这种方式的好处是：应用切换时间很短，可以控制在秒级别。但是缺点也是显而易见的。
对象创建过程十分复杂，需要首先找出对象间相互依赖关系，才能成功创建所有对象。
表与表主外键约束，从而导致了数据插入操作必须先主表，再外表的顺序；数据删除则相反。
将数据转化为DML语句，然后在RDS上执行的方式，效率低下，尤其是大表的情况。
频繁的DML操作语句，非常容易导致RDS上Blocking发生，甚至严重时会产生死锁。
频繁的DML操作，会导致数据日志文件在短时间内暴涨，消耗IOPS资源。
最为严重的缺点是，频繁的DML操作，会导致表索引碎片率在短时间内大幅增加和统计信息的过时，从而导致执行计划评估不准确，进行影响RDS数据库的性能。
物理迁移
为了消除逻辑迁移的种种痛点，物理迁移是指，RDS SQL基于用户的物理备份文件，直接迁移上云还原到RDS SQL上。既然RDS SQL上的数据是基于用户线下数据库备份文件（既可以是完全备份文件，也可以是完全备份文件 + 差异备份或者日志备份文件）直接迁移上云还原到RDS SQL上，那么，我们就可以100%的保证RDS SQL上的数据库和用户线下数据库是100%一致的。就不会存在以上逻辑迁移的种种痛点，而最大的优点体现在解决了索引碎片和统计信息的不一致，导致用户RDS数据库性能问题，保证了用户线下数据库和RDS SQL数据库行为时一致性。
两者对比
逻辑迁移和物理迁移两者的优缺点对比如下所示： 
从对比的结果来看，物理迁移唯一的弱势在于应用切换的时间稍长，控制在分钟级别，但是我相信对于起码95%以上的企业来讲分钟级别的迁移上云应用停止的时间还是可以接受的。
方案解析
在前一个章节，我们详细分析了线下SQL Server数据库迁移上云阿里云RDS SQL的两种方式：逻辑迁移和物理迁移，从对比结果来看，物理迁移具有更多的优点并且复杂度可控，是实现自动化迁移上云的最佳方案。以下两个小节是基于物理迁移上云方案的分析和流程图设计。
方案分析
从整个迁移上云的过程分析来看，主要牵扯到四个方面的参与者，我们只需要把这四个参与者之间关系及用途分析清楚，方案就一目了然了。
用户线下数据库：用户在自己线下环境的SQL Server实例中的数据库。用户需要在线下数据库中完成准备工作、数据库备份及备份文件上传到OSS。
OSS（阿里云对象存储服务）：暂存用户的备份文件，供RDS SQL实例下载备份文件。
RDS控制台：承载着与用户界面交互的功能，用户需要通过RDS控制台告诉阿里云RDS SQL，将哪一个备份文件恢复到哪一个实例的哪一个数据库下。
RDS SQL实例：从OSS下载用户的备份文件，然后还原到RDS实例中。
流程图设计
从“方案分析”中，我们很清楚的了解到迁移上云方案四方参与者，各司其职，各尽所能，就可以很完美的实现用户迁移上云的功能。将整个过程做成流程图，如下所示：
这个流程图，很清楚的描绘了四方参与者之间的职责以及他们的数据流走向。
一个案例
参照上面的“方案解析”部分的介绍，我们举一个特定的案例，来看看阿里云RDS SQL自动迁移上云的案例。
时间轴
首先，从时间维度来看一个典型的上云案例，参照下图所示：
横轴：表示时间，从左往右
数字1 - 9：表示操作步骤先后顺序，和时间对应
数字右边文字：表示操作步骤名称
数字下方文字：表示操作步骤的详细描述信息
案例描述
根据上图增量上云案例，按时间维度，解释如下：
Step1. Before 00:00：完成准备工作，包括完成DBCC CheckDB检查；关闭本地环境备份系统；修改数据库为FULL恢复模式；
Step2. 00:01：用户备份线下数据库开始FULL Backup；
Step3. 02:00：完成FULL Backup，耗时近1小时，开始上传备份文件到OSS Bucket；
Step4. 03:00：完成备份文件上传，耗时1小时，开始在RDS控制台恢复FULL Backup文件；
Step5. 22:00：完成FULL Backup上云，耗时19小时，开始数据库Backup LOG；
Step6. 22:20：完成LOG Backup，耗时20分钟，RDS控制台恢复LOG Backup文件；
Step7. 22:30：完成LOG Backup上云，耗时10分钟，重复步骤5 – 6，不断Backup LOG、上传到OSS、增量上云LOG备份文件，确保最后一个Backup LOG文件尽量小（500MB以下），然后停止本地应用对数据库的写入操作，最后再做一个LOG Backup，最后一次增量上云。
Step8. 22:34：完成了最后一个LOG Backup文件增量上云操作，耗时4分钟，开始将数据库待上线；
Step9. 22:35：数据库上线完毕，如果选择异步执行DBCC操作，上线动作很快，耗时1分钟。
从整个的动作流程和时间轴来看，用户需要停止应用的时间非常的短，仅仅是在最后一个LOG Backup之前停止应用写入即可。在本例中整个应用停止的时间控制在5分钟内。
参考链接
关于SQL Server备份还原理论，我们完成了备份还原专题系列月报六篇，以及基于这些理论设计出了阿里云RDS SQL自动化迁移上云方法。产品介绍参加如下帮助文档：
欢迎大家使用并提出宝贵意见。
