如何从MongoDB迁移到MySQL?这有现成经验!

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 MongoDB,通用型 2核4GB
简介:

如何从MongoDB迁移到MySQL?这有现成经验!

最近的一个多月时间都在做数据库的迁移工作,我目前在开发的项目在上古时代是使用 MySQL 作为主要数据库的,后来由于一些业务上的原因从 MySQL 迁移到了 MongoDB,使用了几个月的时间后,由于数据库服务非常不稳定,再加上无人看管,同时 MongoDB 本身就是无 Schema 的数据库,最后导致数据库的脏数据问题非常严重。目前团队的成员没有较为丰富的 Rails 开发经验,所以还是希望使用 ActiveRecord 加上 Migration 的方式对数据进行一些强限制,保证数据库中数据的合法。

本文会介绍作者在迁移数据库的过程中遇到的一些问题,并为各位读者提供需要停机迁移数据库的可行方案,如果需要不停机迁移数据库还是需要别的方案来解决,在这里提供的方案用于百万数据量的 MongoDB,预计的停机时间在两小时左右,如果数据量在千万级别以上,过长的停机时间可能是无法接受的,应该设计不停机的迁移方案;无论如何,作者希望这篇文章能够给想要做数据库迁移的开发者带来一些思路,少走一些坑。

从关系到文档

虽然这篇文章的重点是从 MongoDB 迁移到 MySQL,但作者还是想简单提一下从 MySQL 到 MongoDB 的迁移,如果我们仅仅是将 MySQL 中的全部数据导入到 MongoDB 中其实是一间比较简单的事情,其中最重要的原因就是 MySQL 支持的数据类型是 MongoDB 的子集:

在迁移的过程中可以将 MySQL 中的全部数据以 csv 的格式导出,然后再将所有 csv 格式的数据使用 mongoimport 全部导入到 MongoDB 中:

 
 
  1. $ mysqldump -u<username> -p<password
  2.  
  3. -T <output_directory> 
  4.  
  5. –fields-terminated-by ‘,’ 
  6.  
  7. –fields-enclosed-by ‘”‘ 
  8.  
  9. –fields-escaped-by ” 
  10.  
  11. no-create-info <database_name> 
  12.  
  13. $ mongoimport –db <database_name> –collection <collection_name> 
  14.  
  15. –type csv 
  16.  
  17. –file <data.csv> 
  18.  
  19. –headerline  

整个过程看起来只需要两个命令,非常简单,但等到你真要去做时你会遇到非常多的问题,作者没有过从 MySQL 或者其它关系型数据库迁移到 MongoDB 的经验,但是 Google 上相关的资料特别多,所以这总是一个有无数前人踩过坑的问题,而前人的经验也能够帮助我们节省很多时间。

使用 csv 的方式导出数据在绝大多数的情况都不会出现问题,但如果数据库中的某些文档中存储的是富文本,那么虽然在导出数据时不会出现问题,最终导入时可能出现一些比较奇怪的错误。

从文档到关系

相比于从 MySQL 到 MongoDB 的迁移,反向的迁移就麻烦了不止一倍,这主要是因为 MongoDB 中的很多数据类型和集合之间的关系在 MySQL 中都并不存在,比如嵌入式的数据结构、数组和哈希等集合类型、多对多关系的实现,很多的问题都不是仅仅能通过数据上的迁移解决的,我们需要在对数据进行迁移之前先对部分数据结构进行重构,本文中的后半部分会介绍需要处理的数据结构和逻辑。

当我们准备将数据库彻底迁移到 MySQL 之前,需要做一些准备工作,将最后迁移所需要的工作尽可能地减少,保证停机的时间不会太长,准备工作的目标就是尽量消灭工程中复杂的数据结构。

数据的预处理

在进行迁移之前要做很多准备工作,第一件事情是要把所有嵌入的数据结构改成非嵌入式的数据结构:

也就是把所有 embeds_many 和 embeds_one 的关系都改成 has_many 和 has_one,同时将 embedded_in 都替换成 belongs_to,同时我们需要将工程中对应的测试都改成这种引用的关系,然而只改变代码中的关系并没有真正改变 MongoDB 中的数据。

 
 
  1. def embeds_many_to_has_many(parent, child) 
  2.  
  3. child_key_name = child.to_s.underscore.pluralize 
  4.  
  5. parent.collection.find({}).each do |parent_document| 
  6.  
  7. next unless parent_document[child_key_name] 
  8.  
  9. parent_document[child_key_name].each do |child_document| 
  10.  
  11. new_child = child_document.merge “#{parent.to_s.underscore}_id”: parent_document[‘_id’] 
  12.  
  13. child.collection.insert_one new_child 
  14.  
  15. end 
  16.  
  17. end 
  18.  
  19. parent.all.unset(child_key_name.to_sym) 
  20.  
  21. end 
  22.  
  23. embeds_many_to_has_many(Person, Address)  

我们可以使用上述的代码将关系为嵌入的模型都转换成引用,拍平所有复杂的数据关系,这段代码的运行时间与嵌入关系中的两个模型的数量有关,需要注意的是,MongoDB 中嵌入模型的数据可能因为某些原因出现相同的 _id 在插入时会发生冲突导致崩溃,你可以对 insert_one 使用 resuce 来保证这段代码的运行不会因为上述原因而停止。

通过这段代码我们就可以轻松将原有的嵌入关系全部展开变成引用的关系,将嵌入的关系变成引用除了做这两个改变之外,不需要做其他的事情,无论是数据的查询还是模型的创建都不需要改变代码的实现,不过记得为子模型中父模型的外键添加索引,否则会导致父模型在获取自己持有的全部子模型时造成全表扫描:

 
 
  1. class Comment 
  2.  
  3. include Mongoid::Document 
  4.  
  5. index post_id: 1 
  6.  
  7. belongs_to :post 
  8.  
  9. end  

在处理了 MongoDB 中独有的嵌入式关系之后,我们就需要解决一些复杂的集合类型了,比如数组和哈希,如果我们使用 MySQL5.7 或者 PostgreSQL 的话,其实并不需要对他们进行处理,因为最新版本的 MySQL 和 PostgreSQL 已经提供了对 JSON 的支持,不过作者还是将项目中的数组和哈希都变成了常见的数据结构。

在这个可选的过程中,其实并没有什么标准答案,我们可以根据需要将不同的数据转换成不同的数据结构:

比如,将数组变成字符串或者一对多关系,将哈希变成当前文档的键值对等等,如何处理这些集合数据其实都要看我们的业务逻辑,在改变这些字段的同时尽量为上层提供一个与原来直接 .tags 或者 .categories 结果相同的 API:

 
 
  1. class Post 
  2.  
  3. … 
  4.  
  5. def tag_titles 
  6.  
  7. tags.map(&:title) 
  8.  
  9. end 
  10.  
  11.  
  12.  
  13. def split_categories 
  14.  
  15. categories.split(‘,’) 
  16.  
  17. end 
  18.  
  19. end  

这一步其实也是可选的,上述代码只是为了减少其它地方的修改负担,当然如果你想使用 MySQL5.7 或者 PostgreSQL 数据库对 JSON 的支持也没有什么太大的问题,只是在查询集合字段时有一些不方便。

Mongoid 的『小兄弟』们

在使用 Mongoid 进行开发期间难免会用到一些相关插件,比如 mongoid-enum、mongoid-slug 和 mongoid-history 等,这些插件的实现与 ActiveRecord 中具有相同功能的插件在实现上有很大的不同。

对于有些插件,比如 mongoid-slug 只是在引入插件的模型的文档中插入了 _slugs 字段,我们只需要在进行数据迁移忽略这些添加的字段并将所有的 #slug 方法改成 #id,不需要在预处理的过程中做其它的改变。而枚举的实现在 Mongoid 的插件和 ActiveRecord 中就截然不同了:

mongoid-enum 使用字符串和 _status 来保存枚举类型的字段,而 ActiveRecord 使用整数和 status 表示枚举类型,两者在底层数据结构的存储上有一些不同,我们会在之后的迁移脚本中解决这个问题。

如果在项目中使用了很多 Mongoid 的插件,由于其实现不同,我们也只能根据不同的插件的具体实现来决定如何对其进行迁移,如果使用了一些支持特殊功能的插件可能很难在 ActiveRecord 中找到对应的支持,在迁移时可以考虑暂时将部分不重要的功能移除。

主键与 UUID

我们希望从 MongoDB 迁移到 MySQL 的另一个重要原因就是 MongoDB 每一个文档的主键实在是太过冗长,一个 32 字节的 _id 无法给我们提供特别多的信息,只能增加我们的阅读障碍,再加上项目中并没有部署 MongoDB 集群,所以没能享受到用默认的 UUID 生成机制带来的好处。

我们不仅没有享受到 UUID 带来的有点,它还在迁移 MySQL 的过程中带来了很大的麻烦,一方面是因为 ActiveRecord 的默认主键是整数,不支持 32 字节长度的 UUID,如果想要不改变 MongoDB 的 UUID,直接迁移到 MySQL 中使用其实也没有什么问题,只是我们要将默认的整数类型的主键变成字符串类型,同时要使用一个 UUID 生成器来保证所有的主键都是根据时间递增的并且不会冲突。

如果准备使用 UUID 加生成器的方式,其实会省去很多迁移的时间,不过看起来确实不是特别的优雅,如何选择还是要权衡和评估,但是如果我们选择了使用 integer 类型的自增主键时,就需要做很多额外的工作了,首先是为所有的表添加 uuid 字段,同时为所有的外键例如 post_id 创建对应的 post_uuid 字段,通过 uuid 将两者关联起来:

在数据的迁移过程中,我们会将原有的 _id 映射到 uuid 中,post_id 映射到 post_uuid 上,我们通过保持 uuid和 post_uuid 之间的关系保证模型之间的关系没有丢失,在迁移数据的过程中 id 和 post_id 是完全不存在任何联系的。

当我们按照 _id 的顺序遍历整个文档,将文档中的数据被插入到表中时,MySQL 会为所有的数据行自动生成的递增的主键 id,而 post_id 在这时都为空。

在全部的数据都被插入到 MySQL 之后,我们通过 #find_by_uuid 查询的方式将 uuid 和 post_uuid 中的关系迁移到 id 和 post_id 中,并将与 uuid 相关的字段全部删除,这样我们能够保证模型之间的关系不会消失,并且数据行的相对位置与迁移前完全一致。

代码的迁移

Mongoid 在使用时都是通过 include 将相关方法加载到当前模型中的,而 ActiveRecord 是通过继承 ActiveRecord::Base 的方式使用的,完成了对数据的预处理,我们就可以对现有模型层的代码进行修改了。

首先当然是更改模型的『父类』,把所有的 Mongoid::Document 都改成 ActiveRecord::Base,然后创建类对应的 Migration 迁移文件:

 
 
  1. # app/models/post.rb 
  2.  
  3. class Post < ActiveRecord::Base 
  4.  
  5. validate_presence_of :title, :content 
  6.  
  7. end 
  8.  
  9. # db/migrate/20170908075625_create_posts.rb 
  10.  
  11. class CreatePosts < ActiveRecord::Migration[5.1] 
  12.  
  13. def change 
  14.  
  15. create_table :posts do |t| 
  16.  
  17. t.string :title, nullfalse 
  18.  
  19. t.text :content, nullfalse 
  20.  
  21. t.string :uuid, nullfalse 
  22.  
  23. t.timestamps nullfalse 
  24.  
  25. end 
  26.  
  27. add_index :posts, :uuid, uniquetrue 
  28.  
  29. end 
  30.  
  31. end  

注意:要为每一张表添加类型为字符串的 uuid 字段,同时为 uuid 建立唯一索引,以加快通过 uuid 建立不同数据模型之间关系的速度。

除了建立数据库的迁移文件并修改基类,我们还需要修改一些 include 的模块和 Mongoid 中独有的查询,比如使用 gte 或者 lte 的日期查询和使用正则进行模式匹配的查询,这些查询在 ActiveRecord 中的使用方式与 Mongoid 中完全不同,我们需要通过手写 SQL 来解决这些问题。

除此之外,我们也需要处理一些复杂的模型关系,比如 Mongoid 中的 inverse_of 在 ActiveRecord 中叫做foreign_key 等等,这些修改其实都并不复杂,只是如果想要将这部分的代码全部处理掉,就需要对业务逻辑进行详细地测试以保证不会有遗留的问题,这也就对我们项目的测试覆盖率有着比较高的要求了,不过我相信绝大多数的 Rails 工程都有着非常好的测试覆盖率,能够保证这一部分代码和逻辑能够顺利迁移,但是如果项目中完全没有测试或者测试覆盖率很低,就只能人肉进行测试或者自求多福了,或者就别做迁移了,多写点测试再考虑这些重构的事情吧。

数据的迁移

为每一个模型创建对应的迁移文件并建表其实一个不得不做的体力活,虽然有一些工作我们没法省略,但是我们可以考虑使用自动化的方式为所有的模型添加 uuid 字段和索引,同时也为类似 post_id 的字段添加相应的 post_uuid 列:

 
 
  1. class AddUuidColumns < ActiveRecord::Migration[5.1] 
  2.  
  3. def change 
  4.  
  5. Rails.application.eager_load! 
  6.  
  7. ActiveRecord::Base.descendants.map do |klass| 
  8.  
  9. add `uuid` column and create unique index on `uuid`. 
  10.  
  11. add_column klass.table_name, :uuid, :string, uniquetrue 
  12.  
  13. add_index klass.table_name, uniquetrue 
  14.  
  15. add `xxx_uuid` columns, ex: `post_uuid`, `comment_uuid` and etc. 
  16.  
  17. uuids = klass.attribute_names 
  18.  
  19. .select { |attr| attr.include? ‘_id’ } 
  20.  
  21. .map    { |attr| attr.gsub ‘_id’, ‘_uuid’ } 
  22.  
  23. next unless uuids.present? 
  24.  
  25. uuids.each do |uuid| 
  26.  
  27. add_column klass.table_name, uuid, :string 
  28.  
  29. end 
  30.  
  31. end 
  32.  
  33. end 
  34.  
  35. end  

在添加 uuid 列并建立好索引之后,我们就可以开始对数据库进行迁移了,如果我们决定在迁移的过程中改变原有数据的主键,那么我们会将迁移分成两个步骤,数据的迁移和关系的重建,前者仅指将 MongoDB 中的所有数据全部迁移到 MySQL 中对应的表中,并将所有的 _id 转换成 uuid、xx_id 转换成 xx_uuid,而后者就是前面提到的:通过 uuid 和 xx_uuid 的关联重新建立模型之间的关系并在最后删除所有的 uuid 字段。

我们可以使用如下的代码对数据进行迁移,这段代码从 MongoDB 中遍历某个集合 Collection 中的全部数据,然后将文档作为参数传入 block,然后再分别通过 DatabaseTransformer#delete_obsolete_columns 和 DatabaseTransformer#update_rename_columns 方法删除部分已有的列、更新一些数据列最后将所有的 id 列都变成 uuid:

 
 
  1. module DatabaseTransformer 
  2.  
  3. def import(collection_name, *obsolete_columns, **rename_columns) 
  4.  
  5. collection = Mongoid::Clients.default.collections.select do |c| 
  6.  
  7. c.namespace == “#{database}.#{collection_name.to_s.pluralize}” 
  8.  
  9. end.first 
  10.  
  11. unless collection.present? 
  12.  
  13. STDOUT.puts “#{collection_name.to_s.yellow}: skipped” 
  14.  
  15. STDOUT.puts 
  16.  
  17. return 
  18.  
  19. end 
  20.  
  21. constant = collection_name.to_s.singularize.camelcase.constantize 
  22.  
  23. reset_callbacks constant 
  24.  
  25. DatabaseTransformer.profiling do 
  26.  
  27. collection_count = collection.find.count 
  28.  
  29. collection.find.each_with_index do |document, index
  30.  
  31. document = yield document if block_given? 
  32.  
  33. delete_obsolete_columns document, obsolete_columns 
  34.  
  35. update_rename_columns document, rename_columns 
  36.  
  37. update_id_columns document 
  38.  
  39. insert_record constant, document 
  40.  
  41. STDOUT.puts “#{index}/#{collection_count} ” if (index % 1000).zero? 
  42.  
  43. end 
  44.  
  45. end 
  46.  
  47. end 
  48.  
  49. end  

当完成了对文档的各种操作之后,该方法会直接调用 DatabaseTransformer#insert_record 将数据插入 MySQL 对应的表中;我们可以直接使用如下的代码将某个 Collection 中的全部文档迁移到 MySQL 中:

 
 
  1. transformer = DatabaseTransformer.new ‘draven_production’ 
  2.  
  3. transformer.import :post, :_slugs, name: :title, _status: :status  

上述代码会在迁移时将集合每一个文档的 _slugs 字段全部忽略,同时将 name 重命名成 title、_status 重命名成 status,虽然作为枚举类型的字段 mongoid-enum 和 ActiveRecord 的枚举类型完全不同,但是在这里可以直接插入也没有什么问题,ActiveRecord 的模型在创建时会自己处理字符串和整数之间的转换:

 
 
  1. def insert_record(constant, params) 
  2.  
  3. model = constant.new params 
  4.  
  5. model.save! validate: false 
  6.  
  7. rescue Exception => exception 
  8.  
  9. STDERR.puts “Import Error: #{exception}” 
  10.  
  11. raise exception 
  12.  
  13. end  

为了加快数据的插入速度,同时避免所有由于插入操作带来的副作用,我们会在数据迁移期间重置所有的回调:

 
 
  1. def reset_callbacks(constant) 
  2.  
  3. %i(create save update).each do |callback| 
  4.  
  5. constant.reset_callbacks callback 
  6.  
  7. end 
  8.  
  9. end  

这段代码的作用仅在这个脚本运行的过程中才会生效,不会对工程中的其他地方造成任何的影响;同时,该脚本会在每 1000 个模型插入成功后向标准输出打印当前进度,帮助我们快速发现问题和预估迁移的时间。

你可以在 database_transformer.rb 找到完整的数据迁移代码。

将所有的数据全部插入到 MySQL 的表之后,模型之间还没有任何显式的关系,我们还需要将通过 uuid 连接的模型转换成使用 id 的方式,对象之间的关系才能通过点语法直接访问,关系的建立其实非常简单,我们获得当前类所有结尾为 _uuid 的属性,然后遍历所有的数据行,根据 uuid 的值和 post_uuid 属性中的 “post” 部分获取到表名,最终得到对应的关联模型,在这里我们也处理了类似多态的特殊情况:

 
 
  1. module RelationBuilder 
  2.  
  3. def build_relations(class_name, polymorphic_associations = [], rename_associations = {}) 
  4.  
  5. uuids = class_name.attribute_names.select { |namename.end_with? ‘_uuid’ } 
  6.  
  7. unless uuids.present? 
  8.  
  9. STDOUT.puts “#{class_name.to_s.yellow}: skipped” 
  10.  
  11. STDOUT.puts 
  12.  
  13. return 
  14.  
  15. end 
  16.  
  17. reset_callbacks class_name 
  18.  
  19. RelationBuilder.profiling do 
  20.  
  21. models_count = class_name.count 
  22.  
  23. class_name.unscoped.all.each_with_index do |model, index
  24.  
  25. update_params = uuids.map do |uuid| 
  26.  
  27. original_association_name = uuid[0…-5] 
  28.  
  29. association_model = association_model( 
  30.  
  31. original_association_name, 
  32.  
  33. model[uuid], 
  34.  
  35. polymorphic_associations, 
  36.  
  37. rename_associations 
  38.  
  39.  
  40. [original_association_name.to_s, association_model] 
  41.  
  42. end.compact 
  43.  
  44. begin 
  45.  
  46. Hash[update_params].each do |key, value| 
  47.  
  48. model.send “#{key}=”, value 
  49.  
  50. end 
  51.  
  52. model.save! validate: false 
  53.  
  54. rescue Exception => e 
  55.  
  56. STDERR.puts e 
  57.  
  58. raise e 
  59.  
  60. end 
  61.  
  62. STDOUT.puts “#{index}/#{models_count} ” if (counter % 1000).zero? 
  63.  
  64. end 
  65.  
  66. end 
  67.  
  68. end 
  69.  
  70. end  

在查找到对应的数据行之后就非常简单了,我们调用对应的 post= 等方法更新外键最后直接将外键的值保存到数据库中,与数据的迁移过程一样,我们在这段代码的执行过程中也会打印出当前的进度。

在初始化 RelationBuilder 时,如果我们传入了 constants,那么在调用 RelationBuilder#build! 时就会重建其中的全部关系,但是如果没有传入就会默认加载 ActiveRecord 中所有的子类,并去掉其中包含 :: 的模型,也就是 ActiveRecord 中使用 has_and_belongs_to_many 创建的中间类,我们会在下一节中介绍如何单独处理多对多关系:

 
 
  1. def initialize(constants = []) 
  2.  
  3. if constants.present? 
  4.  
  5. @constants = constants 
  6.  
  7. else 
  8.  
  9. Rails.application.eager_load! 
  10.  
  11. @constants = ActiveRecord::Base.descendants 
  12.  
  13. .reject { |constant| constant.to_s.include?(‘::’) } 
  14.  
  15. end 
  16.  
  17. end  

跟关系重建相关的代码可以在 relation_builder.rb 找到完整的用于关系迁移的代码。

 
 
  1. builder = RelationBuilder.new([Post, Comment]) 
  2.  
  3. builder.build!  

通过这数据迁移和关系重建两个步骤就已经可以解决绝大部分的数据迁移问题了,但是由于 MongoDB 和 ActiveRecord 中对于多对多关系的处理比较特殊,所以我们需要单独进行解决,如果所有的迁移问题到这里都已经解决了,那么我们就可以使用下面的迁移文件将数据库中与 uuid 有关的全部列都删除了:

 
 
  1. class RemoveAllUuidColumns < ActiveRecord::Migration[5.1] 
  2.  
  3. def change 
  4.  
  5. Rails.application.eager_load! 
  6.  
  7. ActiveRecord::Base.descendants.map do |klass| 
  8.  
  9. attrs = klass.attribute_names.select { |n| n.include? ‘uuid’ } 
  10.  
  11. next unless attrs.present? 
  12.  
  13. remove_columns klass.table_name, *attrs 
  14.  
  15. end 
  16.  
  17. end 
  18.  
  19. end  

到这里位置整个迁移的过程就基本完成了,接下来就是跟整个迁移过程中有关的其它事项,例如:对多对关系、测试的重要性等话题。

多对多关系的处理

多对多关系在数据的迁移过程中其实稍微有一些复杂,在 Mongoid 中使用 has_and_belongs_to_many 会在相关的文档下添加一个 tag_ids 或者 post_ids 数组:

 
 
  1. # The post document. 
  2.  
  3.  
  4. “_id” : ObjectId(“4d3ed089fb60ab534684b7e9”), 
  5.  
  6. “tag_ids” : [ 
  7.  
  8. ObjectId(“4d3ed089fb60ab534684b7f2”), 
  9.  
  10. ObjectId(“4d3ed089fb60ab53468831f1”) 
  11.  
  12. ], 
  13.  
  14. “title”: “xxx”, 
  15.  
  16. “content”: “xxx” 
  17.  
  18.  

而 ActiveRecord 中会建立一张单独的表,表的名称是两张表名按照字母表顺序的拼接,如果是 Post 和 Tag,对应的多对多表就是 posts_tags,除了创建多对多表,has_and_belongs_to_many 还会创建两个 ActiveRecord::Base的子类 Tag::HABTM_Posts 和 Post::HABTM_Tags,我们可以使用下面的代码简单实验一下:

 
 
  1. require ‘active_record’ 
  2.  
  3. class Tag < ActiveRecord::Base; end 
  4.  
  5. class Post < ActiveRecord::Base 
  6.  
  7. has_and_belongs_to_many :tags 
  8.  
  9. end 
  10.  
  11. class Tag < ActiveRecord::Base 
  12.  
  13. has_and_belongs_to_many :posts 
  14.  
  15. end 
  16.  
  17. puts ActiveRecord::Base.descendants  

上述代码打印出了两个 has_and_belongs_to_many 生成的类 Tag::HABTM_Posts 和 Post::HABTM_Tags,它们有着完全相同的表 posts_tags,处理多对多关系时,我们只需要在使用 DatabaseTransformer 导入表中的所有的数据之后,再通过遍历 posts_tags 表中的数据更新多对多的关系表就可以了:

 
 
  1. class PostsTag < ActiveRecord::Base; end 
  2.  
  3. # migrate data from mongodb to mysql. 
  4.  
  5. transformer = DatabaseTransformer.new ‘draven_production’ 
  6.  
  7. transformer.import :posts_tags 
  8.  
  9. # establish association between posts and tags. 
  10.  
  11. PostsTag.unscoped.all.each do |model| 
  12.  
  13. post = Post.find_by_uuid model.post_uuid 
  14.  
  15. tag = Tag.find_by_uuid model.tag_uuid 
  16.  
  17. next unless post.present? && tag.present? 
  18.  
  19. model.update_columns post_id: post.id, tag_id: tag.id 
  20.  
  21. end  

所有使用 has_and_belongs_to_many 的多对多关系都需要通过上述代码进行迁移,这一步需要在删除数据库中的所有 uuid 字段之前完成。

测试的重要性

在真正对线上的服务进行停机迁移之前,我们其实需要对数据库已有的数据进行部分和全量测试,在部分测试阶段,我们可以在本地准备一个数据量为生产环境数据量 1/10 或者 1/100 的 MongoDB 数据库,通过在本地模拟 MongoDB 和 MySQL 的环境进行预迁移,确保我们能够尽快地发现迁移脚本中的错误。

准备测试数据库的办法是通过关系删除一些主要模型的数据行,在删除时可以通过 MongoDB 中的 dependent: :destroy 删除相关的模型,这样可以尽可能的保证数据的一致性和完整性,但是在对线上数据库进行迁移之前,我们依然需要对 MongoDB 中的全部数据进行全量的迁移测试,这样可以发现一些更加隐蔽的问题,保证真正上线时可以出现更少的状况。

数据库的迁移其实也属于重构,在进行 MongoDB 的数据库迁移之前一定要保证项目有着完善的测试体系和测试用例,这样才能让我们在项目重构之后,确定不会出现我们难以预料的问题,整个项目才是可控的,如果工程中没有足够的测试甚至没有测试,那么就不要再说重构这件事情了 – 单元测试是重构的基础。

总结

如何从 MongoDB 迁移到 MySQL 其实是一个工程问题,我们需要在整个过程中不断寻找可能出错的问题,将一个比较复杂的任务进行拆分,在真正做迁移之前尽可能地减少迁移对服务可用性以及稳定性带来的影响。

除此之外,MongoDB 和 MySQL 之间的选择也不一定是非此即彼,我们将项目中的大部分数据都迁移到了 MySQL 中,但是将一部分用于计算和分析的数据留在了 MongoDB,这样就可以保证 MongoDB 宕机之后仍然不会影响项目的主要任务,同时,MySQL 的备份和恢复速度也会因为数据库变小而非常迅速。

最后一点,测试真的很重要,如果没有测试,没有人能够做到在修改大量的业务代码的过程中不丢失任何的业务逻辑,甚至如果没有测试,很多业务逻辑可能在开发的那一天就已经丢失了。  


原文发布时间为:2017-10-20

本文作者:小码哥

本文来自云栖社区合作伙伴“51CTO”,了解相关信息可以关注。

相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。 &nbsp; 相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
4天前
|
弹性计算 关系型数据库 数据库
手把手带你从自建 MySQL 迁移到云数据库,一步就能脱胎换骨
阿里云瑶池数据库来开课啦!自建数据库迁移至云数据库 RDS原来只要一步操作就能搞定!
|
8天前
|
分布式计算 DataWorks MaxCompute
DataWorks产品使用合集之需要将mysql 表(有longtext类型字段) 迁移到odps,但odps好像没有对应的类型支持,该怎么办
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
7天前
|
缓存 分布式计算 关系型数据库
数据管理DMS操作报错合集之当进行RDS实例的可用区迁移时,提示“缓存清理”是什么意思
数据管理DMS(Data Management Service)是阿里云提供的数据库管理和运维服务,它支持多种数据库类型,包括RDS、PolarDB、MongoDB等。在使用DMS进行数据库操作时,可能会遇到各种报错情况。以下是一些常见的DMS操作报错及其可能的原因与解决措施的合集。
|
8天前
|
分布式计算 DataWorks MaxCompute
DataWorks产品使用合集之新创建的工作空间,任务提交了,但是周期实例里面没任何数据,是什么导致的
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
14天前
|
SQL 关系型数据库 MySQL
MySQL 迁移至 SQLite 问题记录
将WPF项目从MySQL迁移到SQLite以简化部署流程。涉及更换Nuget包(Microsoft.Data.Sqlite.Core或System.Data.SQLite),修改SQL语法,如主键和唯一约束的声明,以及处理数据库连接和数据类型差异。SQLite不支持MySQL的truncate语句,需用delete并清理sqlite_sequence表。还需注意逻辑操作符&amp;&amp;需替换为and。更多细节在文中详述。
309 0
|
14天前
|
存储 数据采集 NoSQL
DTS在迁移大数据量的MongoDB数据库时如何保证数据的准确性和完整性?
【6月更文挑战第4天】DTS在迁移大数据量的MongoDB数据库时如何保证数据的准确性和完整性?
84 1
|
1月前
|
关系型数据库 MySQL 分布式数据库
如何将数据从MySQL迁移到PolarDB?
【5月更文挑战第13天】如何将数据从MySQL迁移到PolarDB?
66 0
|
1月前
|
存储 Oracle 关系型数据库
oracle 数据库 迁移 mysql数据库
将 Oracle 数据库迁移到 MySQL 是一项复杂的任务,因为这两种数据库管理系统具有不同的架构、语法和功能。
39 0
|
1月前
|
DataWorks NoSQL 关系型数据库
DataWorks操作报错合集之在使用 DataWorks 进行 MongoDB 同步时遇到了连通性测试失败,实例配置和 MongoDB 白名单配置均正确,且同 VPC 下 MySQL 可以成功连接并同步,但 MongoDB 却无法完成同样的操作如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
1月前
|
关系型数据库 MySQL 测试技术
【专栏】PostgreSQL数据库向MySQL迁移的过程、挑战及策略
【4月更文挑战第29天】本文探讨了PostgreSQL数据库向MySQL迁移的过程、挑战及策略。迁移步骤包括评估规划、数据导出与转换、创建MySQL数据库、数据导入。挑战包括数据类型不匹配、函数和语法差异、数据完整性和性能问题。应对策略涉及数据类型映射、代码调整、数据校验和性能优化。迁移后需进行数据验证、性能测试和业务验证,确保顺利过渡。在数字化时代,掌握数据库迁移技能对技术人员至关重要。