如何实现数据迁移？

Posted 2023-03-23

数据迁移(又称分级存储管理，hierarchical storage management，hsm)是一种将离线存储与在线存储融合的技术。它将高速、高容量的非在线存储设备作为磁盘设备的下一级设备，然后将磁盘中常用的 数据按指定的策略自动迁移到磁带库（简称带库）等二级大容量存储设备上。当需要使用这些数据时，分级存储系统会自动将这些数据从下一级存储设备调回到上一 级磁盘上。对于用户来说，上述数据迁移操作完全是透明的，只是在访问磁盘的速度上略有怠慢，而在逻辑磁盘的容量上明显感觉大大提高了。
数据迁移是将很少使用或不用的文件移到辅助存储系统(如磁带或光盘)的存档过程。这些文件通常是需在未来任何时间可进行方便访问的图像文档或历史信息。迁移工作与备份策略相结合,并且仍要求定期备份。还包括电脑数据迁移，迁移旧电脑（旧系统）中的数据、应用程序、个性化设置等到新电脑（新系统），在系统升级后很有必要。 参考技术A

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

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

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

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

< lower_case_table_names >

https://dev.mysql.com/doc/refman/8.0/en/server-systemvariables.html#sysvar_lower_case_table_names

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

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

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

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

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

参考技术B 方案一、定点停机迁移
停掉应用，用事先写好的迁移程序，把mysql 数据库数据迁移到新结构的mysql数据库中。完成后，切换应用。最大的缺点就是随着数据量的增加停机时间会变得非常长，数据量特别大的有可能需要停机几天，所以不适合数据量特别大的企业。
方案二、MySQL binlog方案
MySQL的迁移可以考虑MySQL的主从复制Replication的特性，解析binlog日志，根据业务需要，对每行数据做特殊处理，把数据写入到新的数据库，运行迁移过程不需要停机。在数据迁移基本上完成的时候，停掉应用，等待迁移全部完成，切换应用到新库。停机时间非常短，只需要几乎1-2分钟或者更少。
方案三、触发器方案
备份老的MySQL数据表结构到新的MySQL数据库，在新库创建新的表结构，更改老的数据库表，创建触发器，让数据写入的时候同时写入到的新的MySQL表。dump老的MySQL的数据，导入到新的MySQL，这是新的MySQL表结构的表应该已经有相应的数据了。然后开启主从复制，让其达到跟主库数据一致。切换应用，迁移到的方案。停机时间非常短，只需要几乎1-2分钟或者更少。
方案四、中间件方案
这种方案必须要你的应用连接数据使用了类似中间层的方案，你只需要在中间层增加同时往新库写数据的代码就好了。

如何实现 IDbContextFactory 以用于实体框架数据迁移

【中文标题】如何实现 IDbContextFactory 以用于实体框架数据迁移

【英文标题】：How to implement IDbContextFactory for use with Entity Framework data migrations

【发布时间】：2012-07-08 20:45:51

【问题描述】：

我正在尝试使用实体框架数据迁移，如this post 中所述。

但是，当我尝试执行 Enable-Migrations 步骤时，我在包管理器控制台中收到以下错误：

The target context 'MyDataContext' is not constructible. Add a default constructor or provide an implementation of IDbContextFactory

因此，我在包含我的 DbContext 类的项目中创建了一个实现 IDbContextFactory 的工厂类，但数据迁移似乎无法识别它。

我应该明确做些什么来指示数据迁移使用这个工厂类吗？

【参考方案1】：

我在编写上下文以获取连接字符串名称（然后使用 ninject 提供它）时也遇到了这个问题。

您所经历的过程似乎是正确的，如果有任何帮助，这里是我的课程实现的 sn-p：

public class MigrationsContextFactory : IDbContextFactory<MyContext>

    public MyContext Create()
    
        return new MyDBContext("connectionStringName");
    

这应该就是你所需要的。

【讨论】：

你把这门课放在哪里了？

我建议将其放入包含您的“MyContext”类的程序集中。我通常会将这样的类保存在单独的程序集中，例如 MyApp.Data.Model 或 MyApp.Domain.Model，类似这些。

能否提供 Ninject 配置代码？我不明白我将在哪里注入 connectionStringName，因为 Create 不采用构造函数参数。

EF如何知道工厂类——MigrationsContextFactory的存在。我们不是必须在某个地方注册它以便框架知道吗？有这个班级独立躺着自给自足吗？蒂姆似乎也承认这不是必需的！

仅供参考 IDbContextFactory 现已过时。请改用IDesignTimeDbContextFactory。

【参考方案2】：

就像@Soren 指出的那样，我们可以实现IDesignTimeDbContextFactory<TContext>，而不是使用一些早期的EF Core 版本（即EF Core 2.1）不支持的IDbContextFactory，它支持缺少的ConnectionString 参数。

对于基于 settings.json 的方法，您可以将其与任何一个引用的接口一起使用，请查看@Arayn's sample，它允许我们定义“ConnectionStrings:DefaultConnection”价值路径

更新 1

根据@PaulWaldman 的评论，重新引入了对IDbContextFactory 的EF Core 5 支持。有关更多详细信息，请查看下面的评论。

【讨论】：

最好将答案标记为重复，而不是仅仅链接到它。

嗨@GertArnold。我不确定你的意思。您似乎在暗示我做错了什么（我可能），但我无法弄清楚。能详细点吗？

您链接到现有的 SO 答案。通常最好将当前问题关闭（标记为）作为您链接到的答案的副本。

其实我从来没有举报过，但从现在开始我会听取你的建议。但是，在这个特定的问题中，我不会，因为这两个问题都针对不同的 EF 接口。无论如何，谢谢你指出它

IDbContextFactory 不再过时。它在 EF Core 5 中重新引入。docs.microsoft.com/en-us/ef/core/dbcontext-configuration/…