作者介紹

Draveness，Rails Dev，擅長Rails Elixir 和 iOS。部落格：https://draveness.me/。

最近的一個多月時間都在做資料庫的遷移工作，我目前在開發的專案在上古時代是使用 MySQL 作為主要資料庫的，後來由於一些業務上的原因從 MySQL 遷移到了 MongoDB，使用了幾個月的時間後，由於資料庫服務非常不穩定，再加上無人看管，同時 MongoDB 本身就是無 Schema 的資料庫，最後導致資料庫的髒資料問題非常嚴重。目前團隊的成員沒有較為豐富的 Rails 開發經驗，所以還是希望使用 ActiveRecord 加上 Migration 的方式對資料進行一些強限制，保證資料庫中資料的合法。

本文會介紹作者在遷移資料庫的過程中遇到的一些問題，併為各位讀者提供需要停機遷移資料庫的可行方案，如果需要不停機遷移資料庫還是需要別的方案來解決，在這裡提供的方案用於百萬資料量的 MongoDB，預計的停機時間在兩小時左右，如果資料量在千萬級別以上，過長的停機時間可能是無法接受的，應該設計不停機的遷移方案；無論如何，作者希望這篇文章能夠給想要做資料庫遷移的開發者帶來一些思路，少走一些坑。

從關係到文件

雖然這篇文章的重點是從 MongoDB 遷移到 MySQL，但作者還是想簡單提一下從 MySQL 到 MongoDB 的遷移，如果我們僅僅是將 MySQL 中的全部資料匯入到 MongoDB 中其實是一間比較簡單的事情，其中最重要的原因就是 MySQL 支援的資料型別是 MongoDB 的子集：

在遷移的過程中可以將 MySQL 中的全部資料以 csv 的格式匯出，然後再將所有 csv 格式的資料使用 mongoimport 全部匯入到 MongoDB 中：

$ mysqldump -u<username> -p<password>

-T <output_directory>

–fields-terminated-by ‘,’

–fields-enclosed-by ‘”‘

–fields-escaped-by ”

–no-create-info <database_name>

$ mongoimport –db <database_name> –collection <collection_name>

–type csv

–file <data.csv>

–headerline

整個過程看起來只需要兩個命令，非常簡單，但等到你真要去做時你會遇到非常多的問題，作者沒有過從 MySQL 或者其它關係型資料庫遷移到 MongoDB 的經驗，但是 Google 上相關的資料特別多，所以這總是一個有無數前人踩過坑的問題，而前人的經驗也能夠幫助我們節省很多時間。

使用 csv 的方式匯出資料在絕大多數的情況都不會出現問題，但如果資料庫中的某些文件中儲存的是富文字，那麼雖然在匯出資料時不會出現問題，最終匯入時可能出現一些比較奇怪的錯誤。

從文件到關係

相比於從 MySQL 到 MongoDB 的遷移，反向的遷移就麻煩了不止一倍，這主要是因為 MongoDB 中的很多資料型別和集合之間的關係在 MySQL 中都並不存在，比如嵌入式的資料結構、陣列和雜湊等集合型別、多對多關係的實現，很多的問題都不是僅僅能通過資料上的遷移解決的，我們需要在對資料進行遷移之前先對部分資料結構進行重構，本文中的後半部分會介紹需要處理的資料結構和邏輯。

當我們準備將資料庫徹底遷移到 MySQL 之前，需要做一些準備工作，將最後遷移所需要的工作儘可能地減少，保證停機的時間不會太長，準備工作的目標就是儘量消滅工程中複雜的資料結構。

資料的預處理

在進行遷移之前要做很多準備工作，第一件事情是要把所有嵌入的資料結構改成非嵌入式的資料結構：

也就是把所有 embeds_many 和 embeds_one 的關係都改成 has_many 和 has_one，同時將 embedded_in 都替換成 belongs_to，同時我們需要將工程中對應的測試都改成這種引用的關係，然而只改變程式碼中的關係並沒有真正改變 MongoDB 中的資料。

def embeds_many_to_has_many(parent, child)

child_key_name = child.to_s.underscore.pluralize

parent.collection.find({}).each do |parent_document|

next unless parent_document[child_key_name]

parent_document[child_key_name].each do |child_document|

new_child = child_document.merge “#{parent.to_s.underscore}_id”: parent_document[‘_id’]

child.collection.insert_one new_child

end

end

parent.all.unset(child_key_name.to_sym)

end

embeds_many_to_has_many(Person, Address)

我們可以使用上述的程式碼將關係為嵌入的模型都轉換成引用，拍平所有複雜的資料關係，這段程式碼的執行時間與嵌入關係中的兩個模型的數量有關，需要注意的是，MongoDB 中嵌入模型的資料可能因為某些原因出現相同的 _id 在插入時會發生衝突導致崩潰，你可以對 insert_one 使用 resuce 來保證這段程式碼的執行不會因為上述原因而停止。

通過這段程式碼我們就可以輕鬆將原有的嵌入關係全部展開變成引用的關係，將嵌入的關係變成引用除了做這兩個改變之外，不需要做其他的事情，無論是資料的查詢還是模型的建立都不需要改變程式碼的實現，不過記得為子模型中父模型的外來鍵新增索引，否則會導致父模型在獲取自己持有的全部子模型時造成全表掃描：

class Comment

include Mongoid::Document

index post_id: 1

belongs_to :post

end

在處理了 MongoDB 中獨有的嵌入式關係之後，我們就需要解決一些複雜的集合型別了，比如陣列和雜湊，如果我們使用 MySQL5.7 或者 PostgreSQL 的話，其實並不需要對他們進行處理，因為最新版本的 MySQL 和 PostgreSQL 已經提供了對 JSON 的支援，不過作者還是將專案中的陣列和雜湊都變成了常見的資料結構。

在這個可選的過程中，其實並沒有什麼標準答案，我們可以根據需要將不同的資料轉換成不同的資料結構：

比如，將陣列變成字串或者一對多關係，將雜湊變成當前文件的鍵值對等等，如何處理這些集合資料其實都要看我們的業務邏輯，在改變這些欄位的同時儘量為上層提供一個與原來直接 .tags 或者 .categories 結果相同的 API：

class Post

…

def tag_titles

tags.map(&:title)

end

def split_categories

categories.split(‘,’)

end

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 遷移檔案：

# app/models/post.rb

class Post < ActiveRecord::Base

validate_presence_of :title, :content

end

# db/migrate/20170908075625_create_posts.rb

class CreatePosts < ActiveRecord::Migration[5.1]

def change

create_table :posts do |t|

t.string :title, null: false

t.text :content, null: false

t.string :uuid, null: false

t.timestamps null: false

end

add_index :posts, :uuid, unique: true

end

end

注意：要為每一張表新增型別為字串的 uuid 欄位，同時為 uuid 建立唯一索引，以加快通過 uuid 建立不同資料模型之間關係的速度。

除了建立資料庫的遷移檔案並修改基類，我們還需要修改一些 include 的模組和 Mongoid 中獨有的查詢，比如使用 gte 或者 lte 的日期查詢和使用正則進行模式匹配的查詢，這些查詢在 ActiveRecord 中的使用方式與 Mongoid 中完全不同，我們需要通過手寫 SQL 來解決這些問題。

除此之外，我們也需要處理一些複雜的模型關係，比如 Mongoid 中的 inverse_of 在 ActiveRecord 中叫做foreign_key 等等，這些修改其實都並不複雜，只是如果想要將這部分的程式碼全部處理掉，就需要對業務邏輯進行詳細地測試以保證不會有遺留的問題，這也就對我們專案的測試覆蓋率有著比較高的要求了，不過我相信絕大多數的 Rails 工程都有著非常好的測試覆蓋率，能夠保證這一部分程式碼和邏輯能夠順利遷移，但是如果專案中完全沒有測試或者測試覆蓋率很低，就只能人肉進行測試或者自求多福了，或者就別做遷移了，多寫點測試再考慮這些重構的事情吧。

資料的遷移

為每一個模型建立對應的遷移檔案並建表其實一個不得不做的體力活，雖然有一些工作我們沒法省略，但是我們可以考慮使用自動化的方式為所有的模型新增 uuid 欄位和索引，同時也為類似 post_id 的欄位新增相應的 post_uuid 列：

class AddUuidColumns < ActiveRecord::Migration[5.1]

def change

Rails.application.eager_load!

ActiveRecord::Base.descendants.map do |klass|

# add `uuid` column and create unique index on `uuid`.

add_column klass.table_name, :uuid, :string, unique: true

add_index klass.table_name, unique: true

# add `xxx_uuid` columns, ex: `post_uuid`, `comment_uuid` and etc.

uuids = klass.attribute_names

.select { |attr| attr.include? ‘_id’ }

.map    { |attr| attr.gsub ‘_id’, ‘_uuid’ }

next unless uuids.present?

uuids.each do |uuid|

add_column klass.table_name, uuid, :string

end

end

end

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：

module DatabaseTransformer

def import(collection_name, *obsolete_columns, **rename_columns)

collection = Mongoid::Clients.default.collections.select do |c|

c.namespace == “#{database}.#{collection_name.to_s.pluralize}”

end.first

unless collection.present?

STDOUT.puts “#{collection_name.to_s.yellow}: skipped”

STDOUT.puts

return

end

constant = collection_name.to_s.singularize.camelcase.constantize

reset_callbacks constant

DatabaseTransformer.profiling do

collection_count = collection.find.count

collection.find.each_with_index do |document, index|

document = yield document if block_given?

delete_obsolete_columns document, obsolete_columns

update_rename_columns document, rename_columns

update_id_columns document

insert_record constant, document

STDOUT.puts “#{index}/#{collection_count} ” if (index % 1000).zero?

end

end

end

end

當完成了對文件的各種操作之後，該方法會直接呼叫 DatabaseTransformer#insert_record 將資料插入 MySQL 對應的表中；我們可以直接使用如下的程式碼將某個 Collection 中的全部文件遷移到 MySQL 中：

transformer = DatabaseTransformer.new ‘draven_production’

transformer.import :post, :_slugs, name: :title, _status: :status

上述程式碼會在遷移時將集合每一個文件的 _slugs 欄位全部忽略，同時將 name 重新命名成 title、_status 重新命名成 status，雖然作為列舉型別的欄位 mongoid-enum 和 ActiveRecord 的列舉型別完全不同，但是在這裡可以直接插入也沒有什麼問題，ActiveRecord 的模型在建立時會自己處理字串和整數之間的轉換：

def insert_record(constant, params)

model = constant.new params

model.save! validate: false

rescue Exception => exception

STDERR.puts “Import Error: #{exception}”

raise exception

end

為了加快資料的插入速度，同時避免所有由於插入操作帶來的副作用，我們會在資料遷移期間重置所有的回撥：

def reset_callbacks(constant)

%i(create save update).each do |callback|

constant.reset_callbacks callback

end

end

這段程式碼的作用僅在這個指令碼執行的過程中才會生效，不會對工程中的其他地方造成任何的影響；同時，該指令碼會在每 1000 個模型插入成功後向標準輸出列印當前進度，幫助我們快速發現問題和預估遷移的時間。

你可以在 database_transformer.rb  找到完整的資料遷移程式碼。

將所有的資料全部插入到 MySQL 的表之後，模型之間還沒有任何顯式的關係，我們還需要將通過 uuid 連線的模型轉換成使用 id 的方式，物件之間的關係才能通過點語法直接訪問，關係的建立其實非常簡單，我們獲得當前類所有結尾為 _uuid 的屬性，然後遍歷所有的資料行，根據 uuid 的值和 post_uuid 屬性中的 “post” 部分獲取到表名，最終得到對應的關聯模型，在這裡我們也處理了類似多型的特殊情況：

module RelationBuilder

def build_relations(class_name, polymorphic_associations = [], rename_associations = {})

uuids = class_name.attribute_names.select { |name| name.end_with? ‘_uuid’ }

unless uuids.present?

STDOUT.puts “#{class_name.to_s.yellow}: skipped”

STDOUT.puts

return

end

reset_callbacks class_name

RelationBuilder.profiling do

models_count = class_name.count

class_name.unscoped.all.each_with_index do |model, index|

update_params = uuids.map do |uuid|

original_association_name = uuid[0…-5]

association_model = association_model(

original_association_name,

model[uuid],

polymorphic_associations,

rename_associations

)

[original_association_name.to_s, association_model]

end.compact

begin

Hash[update_params].each do |key, value|

model.send “#{key}=”, value

end

model.save! validate: false

rescue Exception => e

STDERR.puts e

raise e

end

STDOUT.puts “#{index}/#{models_count} ” if (counter % 1000).zero?

end

end

end

end

在查詢到對應的資料行之後就非常簡單了，我們呼叫對應的 post= 等方法更新外來鍵最後直接將外來鍵的值儲存到資料庫中，與資料的遷移過程一樣，我們在這段程式碼的執行過程中也會打印出當前的進度。

在初始化 RelationBuilder 時，如果我們傳入了 constants，那麼在呼叫 RelationBuilder#build! 時就會重建其中的全部關係，但是如果沒有傳入就會預設載入 ActiveRecord 中所有的子類，並去掉其中包含 :: 的模型，也就是 ActiveRecord 中使用 has_and_belongs_to_many 建立的中間類，我們會在下一節中介紹如何單獨處理多對多關係：

def initialize(constants = [])

if constants.present?

@constants = constants

else

Rails.application.eager_load!

@constants = ActiveRecord::Base.descendants

.reject { |constant| constant.to_s.include?(‘::’) }

end

end

跟關係重建相關的程式碼可以在 relation_builder.rb  找到完整的用於關係遷移的程式碼。

builder = RelationBuilder.new([Post, Comment])

builder.build!

通過這資料遷移和關係重建兩個步驟就已經可以解決絕大部分的資料遷移問題了，但是由於 MongoDB 和 ActiveRecord 中對於多對多關係的處理比較特殊，所以我們需要單獨進行解決，如果所有的遷移問題到這裡都已經解決了，那麼我們就可以使用下面的遷移檔案將資料庫中與 uuid 有關的全部列都刪除了：

class RemoveAllUuidColumns < ActiveRecord::Migration[5.1]

def change

Rails.application.eager_load!

ActiveRecord::Base.descendants.map do |klass|

attrs = klass.attribute_names.select { |n| n.include? ‘uuid’ }

next unless attrs.present?

remove_columns klass.table_name, *attrs

end

end

end

到這裡位置整個遷移的過程就基本完成了，接下來就是跟整個遷移過程中有關的其它事項，例如：對多對關係、測試的重要性等話題。

多對多關係的處理

多對多關係在資料的遷移過程中其實稍微有一些複雜，在 Mongoid 中使用 has_and_belongs_to_many 會在相關的文件下新增一個 tag_ids 或者 post_ids 陣列：

# The post document.

{

“_id” : ObjectId(“4d3ed089fb60ab534684b7e9”),

“tag_ids” : [

ObjectId(“4d3ed089fb60ab534684b7f2”),

ObjectId(“4d3ed089fb60ab53468831f1”)

],

“title”: “xxx”,

“content”: “xxx”

}

而 ActiveRecord 中會建立一張單獨的表，表的名稱是兩張表名按照字母表順序的拼接，如果是 Post 和 Tag，對應的多對多表就是 posts_tags，除了建立多對多表，has_and_belongs_to_many 還會建立兩個 ActiveRecord::Base的子類 Tag::HABTM_Posts 和 Post::HABTM_Tags，我們可以使用下面的程式碼簡單實驗一下：

require ‘active_record’

class Tag < ActiveRecord::Base; end

class Post < ActiveRecord::Base

has_and_belongs_to_many :tags

end

class Tag < ActiveRecord::Base

has_and_belongs_to_many :posts

end

puts ActiveRecord::Base.descendants

上述程式碼打印出了兩個 has_and_belongs_to_many 生成的類 Tag::HABTM_Posts 和 Post::HABTM_Tags，它們有著完全相同的表 posts_tags，處理多對多關係時，我們只需要在使用 DatabaseTransformer 匯入表中的所有的資料之後，再通過遍歷 posts_tags 表中的資料更新多對多的關係表就可以了：

class PostsTag < ActiveRecord::Base; end

# migrate data from mongodb to mysql.

transformer = DatabaseTransformer.new ‘draven_production’

transformer.import :posts_tags

# establish association between posts and tags.

PostsTag.unscoped.all.each do |model|

post = Post.find_by_uuid model.post_uuid

tag = Tag.find_by_uuid model.tag_uuid

next unless post.present? && tag.present?

model.update_columns post_id: post.id, tag_id: tag.id

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 的備份和恢復速度也會因為資料庫變小而非常迅速。

最後一點，測試真的很重要，如果沒有測試，沒有人能夠做到在修改大量的業務程式碼的過程中不丟失任何的業務邏輯，甚至如果沒有測試，很多業務邏輯可能在開發的那一天就已經丟失了。

原文來自微信公眾號：DBAplus社群