[[207004]]

最近的一個(gè)多月時(shí)間都在做數(shù)據(jù)庫(kù)的遷移工作，我目前在開(kāi)發(fā)的項(xiàng)目在上古時(shí)代是使用 MySQL 作為主要數(shù)據(jù)庫(kù)的，后來(lái)由于一些業(yè)務(wù)上的原因從 MySQL 遷移到了 MongoDB，使用了幾個(gè)月的時(shí)間后，由于數(shù)據(jù)庫(kù)服務(wù)非常不穩(wěn)定，再加上無(wú)人看管，同時(shí) MongoDB 本身就是無(wú) Schema 的數(shù)據(jù)庫(kù)，***導(dǎo)致數(shù)據(jù)庫(kù)的臟數(shù)據(jù)問(wèn)題非常嚴(yán)重。目前團(tuán)隊(duì)的成員沒(méi)有較為豐富的 Rails 開(kāi)發(fā)經(jīng)驗(yàn)，所以還是希望使用 ActiveRecord 加上 Migration 的方式對(duì)數(shù)據(jù)進(jìn)行一些強(qiáng)限制，保證數(shù)據(jù)庫(kù)中數(shù)據(jù)的合法。

本文會(huì)介紹作者在遷移數(shù)據(jù)庫(kù)的過(guò)程中遇到的一些問(wèn)題，并為各位讀者提供需要停機(jī)遷移數(shù)據(jù)庫(kù)的可行方案，如果需要不停機(jī)遷移數(shù)據(jù)庫(kù)還是需要?jiǎng)e的方案來(lái)解決，在這里提供的方案用于百萬(wàn)數(shù)據(jù)量的 MongoDB，預(yù)計(jì)的停機(jī)時(shí)間在兩小時(shí)左右，如果數(shù)據(jù)量在***別以上，過(guò)長(zhǎng)的停機(jī)時(shí)間可能是無(wú)法接受的，應(yīng)該設(shè)計(jì)不停機(jī)的遷移方案;無(wú)論如何，作者希望這篇文章能夠給想要做數(shù)據(jù)庫(kù)遷移的開(kāi)發(fā)者帶來(lái)一些思路，少走一些坑。

從關(guān)系到文檔

雖然這篇文章的重點(diǎn)是從 MongoDB 遷移到 MySQL，但作者還是想簡(jiǎn)單提一下從 MySQL 到 MongoDB 的遷移，如果我們僅僅是將 MySQL 中的全部數(shù)據(jù)導(dǎo)入到 MongoDB 中其實(shí)是一間比較簡(jiǎn)單的事情，其中最重要的原因就是 MySQL 支持的數(shù)據(jù)類型是 MongoDB 的子集：

在遷移的過(guò)程中可以將 MySQL 中的全部數(shù)據(jù)以 csv 的格式導(dǎo)出，然后再將所有 csv 格式的數(shù)據(jù)使用 mongoimport 全部導(dǎo)入到 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  

整個(gè)過(guò)程看起來(lái)只需要兩個(gè)命令，非常簡(jiǎn)單，但等到你真要去做時(shí)你會(huì)遇到非常多的問(wèn)題，作者沒(méi)有過(guò)從 MySQL 或者其它關(guān)系型數(shù)據(jù)庫(kù)遷移到 MongoDB 的經(jīng)驗(yàn)，但是 Google 上相關(guān)的資料特別多，所以這總是一個(gè)有無(wú)數(shù)前人踩過(guò)坑的問(wèn)題，而前人的經(jīng)驗(yàn)也能夠幫助我們節(jié)省很多時(shí)間。

使用 csv 的方式導(dǎo)出數(shù)據(jù)在絕大多數(shù)的情況都不會(huì)出現(xiàn)問(wèn)題，但如果數(shù)據(jù)庫(kù)中的某些文檔中存儲(chǔ)的是富文本，那么雖然在導(dǎo)出數(shù)據(jù)時(shí)不會(huì)出現(xiàn)問(wèn)題，最終導(dǎo)入時(shí)可能出現(xiàn)一些比較奇怪的錯(cuò)誤。

從文檔到關(guān)系

相比于從 MySQL 到 MongoDB 的遷移，反向的遷移就麻煩了不止一倍，這主要是因?yàn)?MongoDB 中的很多數(shù)據(jù)類型和集合之間的關(guān)系在 MySQL 中都并不存在，比如嵌入式的數(shù)據(jù)結(jié)構(gòu)、數(shù)組和哈希等集合類型、多對(duì)多關(guān)系的實(shí)現(xiàn)，很多的問(wèn)題都不是僅僅能通過(guò)數(shù)據(jù)上的遷移解決的，我們需要在對(duì)數(shù)據(jù)進(jìn)行遷移之前先對(duì)部分?jǐn)?shù)據(jù)結(jié)構(gòu)進(jìn)行重構(gòu)，本文中的后半部分會(huì)介紹需要處理的數(shù)據(jù)結(jié)構(gòu)和邏輯。

當(dāng)我們準(zhǔn)備將數(shù)據(jù)庫(kù)徹底遷移到 MySQL 之前，需要做一些準(zhǔn)備工作，將***遷移所需要的工作盡可能地減少，保證停機(jī)的時(shí)間不會(huì)太長(zhǎng)，準(zhǔn)備工作的目標(biāo)就是盡量消滅工程中復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

數(shù)據(jù)的預(yù)處理

在進(jìn)行遷移之前要做很多準(zhǔn)備工作，***件事情是要把所有嵌入的數(shù)據(jù)結(jié)構(gòu)改成非嵌入式的數(shù)據(jù)結(jié)構(gòu)： 

也就是把所有 embeds_many 和 embeds_one 的關(guān)系都改成 has_many 和 has_one，同時(shí)將 embedded_in 都替換成 belongs_to，同時(shí)我們需要將工程中對(duì)應(yīng)的測(cè)試都改成這種引用的關(guān)系，然而只改變代碼中的關(guān)系并沒(méi)有真正改變 MongoDB 中的數(shù)據(jù)。

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)  

我們可以使用上述的代碼將關(guān)系為嵌入的模型都轉(zhuǎn)換成引用，拍平所有復(fù)雜的數(shù)據(jù)關(guān)系，這段代碼的運(yùn)行時(shí)間與嵌入關(guān)系中的兩個(gè)模型的數(shù)量有關(guān)，需要注意的是，MongoDB 中嵌入模型的數(shù)據(jù)可能因?yàn)槟承┰虺霈F(xiàn)相同的 _id 在插入時(shí)會(huì)發(fā)生沖突導(dǎo)致崩潰，你可以對(duì) insert_one 使用 resuce 來(lái)保證這段代碼的運(yùn)行不會(huì)因?yàn)樯鲜鲈蚨Ｖ埂?/p>

通過(guò)這段代碼我們就可以輕松將原有的嵌入關(guān)系全部展開(kāi)變成引用的關(guān)系，將嵌入的關(guān)系變成引用除了做這兩個(gè)改變之外，不需要做其他的事情，無(wú)論是數(shù)據(jù)的查詢還是模型的創(chuàng)建都不需要改變代碼的實(shí)現(xiàn)，不過(guò)記得為子模型中父模型的外鍵添加索引，否則會(huì)導(dǎo)致父模型在獲取自己持有的全部子模型時(shí)造成全表掃描：

class Comment 
 
include Mongoid::Document 
 
index post_id: 1 
 
belongs_to :post 
 
end  

在處理了 MongoDB 中獨(dú)有的嵌入式關(guān)系之后，我們就需要解決一些復(fù)雜的集合類型了，比如數(shù)組和哈希，如果我們使用 MySQL5.7 或者 PostgreSQL 的話，其實(shí)并不需要對(duì)他們進(jìn)行處理，因?yàn)?**版本的 MySQL 和 PostgreSQL 已經(jīng)提供了對(duì) JSON 的支持，不過(guò)作者還是將項(xiàng)目中的數(shù)組和哈希都變成了常見(jiàn)的數(shù)據(jù)結(jié)構(gòu)。

在這個(gè)可選的過(guò)程中，其實(shí)并沒(méi)有什么標(biāo)準(zhǔn)答案，我們可以根據(jù)需要將不同的數(shù)據(jù)轉(zhuǎn)換成不同的數(shù)據(jù)結(jié)構(gòu)：

比如，將數(shù)組變成字符串或者一對(duì)多關(guān)系，將哈希變成當(dāng)前文檔的鍵值對(duì)等等，如何處理這些集合數(shù)據(jù)其實(shí)都要看我們的業(yè)務(wù)邏輯，在改變這些字段的同時(shí)盡量為上層提供一個(gè)與原來(lái)直接 .tags 或者 .categories 結(jié)果相同的 API：

class Post 
 
… 
 
def tag_titles 
 
tags.map(&:title) 
 
end 
 
 
 
def split_categories 
 
categories.split(‘,’) 
 
end 
 
end  

這一步其實(shí)也是可選的，上述代碼只是為了減少其它地方的修改負(fù)擔(dān)，當(dāng)然如果你想使用 MySQL5.7 或者 PostgreSQL 數(shù)據(jù)庫(kù)對(duì) JSON 的支持也沒(méi)有什么太大的問(wèn)題，只是在查詢集合字段時(shí)有一些不方便。

Mongoid 的『小兄弟』們

在使用 Mongoid 進(jìn)行開(kāi)發(fā)期間難免會(huì)用到一些相關(guān)插件，比如 mongoid-enum、mongoid-slug 和 mongoid-history 等，這些插件的實(shí)現(xiàn)與 ActiveRecord 中具有相同功能的插件在實(shí)現(xiàn)上有很大的不同。

對(duì)于有些插件，比如 mongoid-slug 只是在引入插件的模型的文檔中插入了 _slugs 字段，我們只需要在進(jìn)行數(shù)據(jù)遷移忽略這些添加的字段并將所有的 #slug 方法改成 #id，不需要在預(yù)處理的過(guò)程中做其它的改變。而枚舉的實(shí)現(xiàn)在 Mongoid 的插件和 ActiveRecord 中就截然不同了：

mongoid-enum 使用字符串和 _status 來(lái)保存枚舉類型的字段，而 ActiveRecord 使用整數(shù)和 status 表示枚舉類型，兩者在底層數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)上有一些不同，我們會(huì)在之后的遷移腳本中解決這個(gè)問(wèn)題。

如果在項(xiàng)目中使用了很多 Mongoid 的插件，由于其實(shí)現(xiàn)不同，我們也只能根據(jù)不同的插件的具體實(shí)現(xiàn)來(lái)決定如何對(duì)其進(jìn)行遷移，如果使用了一些支持特殊功能的插件可能很難在 ActiveRecord 中找到對(duì)應(yīng)的支持，在遷移時(shí)可以考慮暫時(shí)將部分不重要的功能移除。

主鍵與 UUID

我們希望從 MongoDB 遷移到 MySQL 的另一個(gè)重要原因就是 MongoDB 每一個(gè)文檔的主鍵實(shí)在是太過(guò)冗長(zhǎng)，一個(gè) 32 字節(jié)的 _id 無(wú)法給我們提供特別多的信息，只能增加我們的閱讀障礙，再加上項(xiàng)目中并沒(méi)有部署 MongoDB 集群，所以沒(méi)能享受到用默認(rèn)的 UUID 生成機(jī)制帶來(lái)的好處。

我們不僅沒(méi)有享受到 UUID 帶來(lái)的有點(diǎn)，它還在遷移 MySQL 的過(guò)程中帶來(lái)了很大的麻煩，一方面是因?yàn)?ActiveRecord 的默認(rèn)主鍵是整數(shù)，不支持 32 字節(jié)長(zhǎng)度的 UUID，如果想要不改變 MongoDB 的 UUID，直接遷移到 MySQL 中使用其實(shí)也沒(méi)有什么問(wèn)題，只是我們要將默認(rèn)的整數(shù)類型的主鍵變成字符串類型，同時(shí)要使用一個(gè) UUID 生成器來(lái)保證所有的主鍵都是根據(jù)時(shí)間遞增的并且不會(huì)沖突。

如果準(zhǔn)備使用 UUID 加生成器的方式，其實(shí)會(huì)省去很多遷移的時(shí)間，不過(guò)看起來(lái)確實(shí)不是特別的優(yōu)雅，如何選擇還是要權(quán)衡和評(píng)估，但是如果我們選擇了使用 integer 類型的自增主鍵時(shí)，就需要做很多額外的工作了，首先是為所有的表添加 uuid 字段，同時(shí)為所有的外鍵例如 post_id 創(chuàng)建對(duì)應(yīng)的 post_uuid 字段，通過(guò) uuid 將兩者關(guān)聯(lián)起來(lái)：

在數(shù)據(jù)的遷移過(guò)程中，我們會(huì)將原有的 _id 映射到 uuid 中，post_id 映射到 post_uuid 上，我們通過(guò)保持 uuid和 post_uuid 之間的關(guān)系保證模型之間的關(guān)系沒(méi)有丟失，在遷移數(shù)據(jù)的過(guò)程中 id 和 post_id 是完全不存在任何聯(lián)系的。

當(dāng)我們按照 _id 的順序遍歷整個(gè)文檔，將文檔中的數(shù)據(jù)被插入到表中時(shí)，MySQL 會(huì)為所有的數(shù)據(jù)行自動(dòng)生成的遞增的主鍵 id，而 post_id 在這時(shí)都為空。

在全部的數(shù)據(jù)都被插入到 MySQL 之后，我們通過(guò) #find_by_uuid 查詢的方式將 uuid 和 post_uuid 中的關(guān)系遷移到 id 和 post_id 中，并將與 uuid 相關(guān)的字段全部刪除，這樣我們能夠保證模型之間的關(guān)系不會(huì)消失，并且數(shù)據(jù)行的相對(duì)位置與遷移前完全一致。

代碼的遷移

Mongoid 在使用時(shí)都是通過(guò) include 將相關(guān)方法加載到當(dāng)前模型中的，而 ActiveRecord 是通過(guò)繼承 ActiveRecord::Base 的方式使用的，完成了對(duì)數(shù)據(jù)的預(yù)處理，我們就可以對(duì)現(xiàn)有模型層的代碼進(jìn)行修改了。

首先當(dāng)然是更改模型的『父類』，把所有的 Mongoid::Document 都改成 ActiveRecord::Base，然后創(chuàng)建類對(duì)應(yīng)的 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 字段，同時(shí)為 uuid 建立唯一索引，以加快通過(guò) uuid 建立不同數(shù)據(jù)模型之間關(guān)系的速度。

除了建立數(shù)據(jù)庫(kù)的遷移文件并修改基類，我們還需要修改一些 include 的模塊和 Mongoid 中獨(dú)有的查詢，比如使用 gte 或者 lte 的日期查詢和使用正則進(jìn)行模式匹配的查詢，這些查詢?cè)?ActiveRecord 中的使用方式與 Mongoid 中完全不同，我們需要通過(guò)手寫(xiě) SQL 來(lái)解決這些問(wèn)題。 

除此之外，我們也需要處理一些復(fù)雜的模型關(guān)系，比如 Mongoid 中的 inverse_of 在 ActiveRecord 中叫做foreign_key 等等，這些修改其實(shí)都并不復(fù)雜，只是如果想要將這部分的代碼全部處理掉，就需要對(duì)業(yè)務(wù)邏輯進(jìn)行詳細(xì)地測(cè)試以保證不會(huì)有遺留的問(wèn)題，這也就對(duì)我們項(xiàng)目的測(cè)試覆蓋率有著比較高的要求了，不過(guò)我相信絕大多數(shù)的 Rails 工程都有著非常好的測(cè)試覆蓋率，能夠保證這一部分代碼和邏輯能夠順利遷移，但是如果項(xiàng)目中完全沒(méi)有測(cè)試或者測(cè)試覆蓋率很低，就只能人肉進(jìn)行測(cè)試或者自求多福了，或者就別做遷移了，多寫(xiě)點(diǎn)測(cè)試再考慮這些重構(gòu)的事情吧。

數(shù)據(jù)的遷移

為每一個(gè)模型創(chuàng)建對(duì)應(yīng)的遷移文件并建表其實(shí)一個(gè)不得不做的體力活，雖然有一些工作我們沒(méi)法省略，但是我們可以考慮使用自動(dòng)化的方式為所有的模型添加 uuid 字段和索引，同時(shí)也為類似 post_id 的字段添加相應(yīng)的 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 列并建立好索引之后，我們就可以開(kāi)始對(duì)數(shù)據(jù)庫(kù)進(jìn)行遷移了，如果我們決定在遷移的過(guò)程中改變?cè)袛?shù)據(jù)的主鍵，那么我們會(huì)將遷移分成兩個(gè)步驟，數(shù)據(jù)的遷移和關(guān)系的重建，前者僅指將 MongoDB 中的所有數(shù)據(jù)全部遷移到 MySQL 中對(duì)應(yīng)的表中，并將所有的 _id 轉(zhuǎn)換成 uuid、xx_id 轉(zhuǎn)換成 xx_uuid，而后者就是前面提到的：通過(guò) uuid 和 xx_uuid 的關(guān)聯(lián)重新建立模型之間的關(guān)系并在***刪除所有的 uuid 字段。

我們可以使用如下的代碼對(duì)數(shù)據(jù)進(jìn)行遷移，這段代碼從 MongoDB 中遍歷某個(gè)集合 Collection 中的全部數(shù)據(jù)，然后將文檔作為參數(shù)傳入 block，然后再分別通過(guò) DatabaseTransformer#delete_obsolete_columns 和 DatabaseTransformer#update_rename_columns 方法刪除部分已有的列、更新一些數(shù)據(jù)列***將所有的 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  

當(dāng)完成了對(duì)文檔的各種操作之后，該方法會(huì)直接調(diào)用 DatabaseTransformer#insert_record 將數(shù)據(jù)插入 MySQL 對(duì)應(yīng)的表中;我們可以直接使用如下的代碼將某個(gè) Collection 中的全部文檔遷移到 MySQL 中：

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

上述代碼會(huì)在遷移時(shí)將集合每一個(gè)文檔的 _slugs 字段全部忽略，同時(shí)將 name 重命名成 title、_status 重命名成 status，雖然作為枚舉類型的字段 mongoid-enum 和 ActiveRecord 的枚舉類型完全不同，但是在這里可以直接插入也沒(méi)有什么問(wèn)題，ActiveRecord 的模型在創(chuàng)建時(shí)會(huì)自己處理字符串和整數(shù)之間的轉(zhuǎn)換：

def insert_record(constant, params) 
 
model = constant.new params 
 
model.save! validate: false 
 
rescue Exception => exception 
 
STDERR.puts “Import Error: #{exception}” 
 
raise exception 
 
end  

為了加快數(shù)據(jù)的插入速度，同時(shí)避免所有由于插入操作帶來(lái)的副作用，我們會(huì)在數(shù)據(jù)遷移期間重置所有的回調(diào)：

def reset_callbacks(constant) 
 
%i(create save update).each do |callback| 
 
constant.reset_callbacks callback 
 
end 
 
end  

這段代碼的作用僅在這個(gè)腳本運(yùn)行的過(guò)程中才會(huì)生效，不會(huì)對(duì)工程中的其他地方造成任何的影響;同時(shí)，該腳本會(huì)在每 1000 個(gè)模型插入成功后向標(biāo)準(zhǔn)輸出打印當(dāng)前進(jìn)度，幫助我們快速發(fā)現(xiàn)問(wèn)題和預(yù)估遷移的時(shí)間。

你可以在 database_transformer.rb 找到完整的數(shù)據(jù)遷移代碼。

將所有的數(shù)據(jù)全部插入到 MySQL 的表之后，模型之間還沒(méi)有任何顯式的關(guān)系，我們還需要將通過(guò) uuid 連接的模型轉(zhuǎn)換成使用 id 的方式，對(duì)象之間的關(guān)系才能通過(guò)點(diǎn)語(yǔ)法直接訪問(wèn)，關(guān)系的建立其實(shí)非常簡(jiǎn)單，我們獲得當(dāng)前類所有結(jié)尾為 _uuid 的屬性，然后遍歷所有的數(shù)據(jù)行，根據(jù) uuid 的值和 post_uuid 屬性中的 “post” 部分獲取到表名，最終得到對(duì)應(yīng)的關(guān)聯(lián)模型，在這里我們也處理了類似多態(tài)的特殊情況：

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  

在查找到對(duì)應(yīng)的數(shù)據(jù)行之后就非常簡(jiǎn)單了，我們調(diào)用對(duì)應(yīng)的 post= 等方法更新外鍵***直接將外鍵的值保存到數(shù)據(jù)庫(kù)中，與數(shù)據(jù)的遷移過(guò)程一樣，我們?cè)谶@段代碼的執(zhí)行過(guò)程中也會(huì)打印出當(dāng)前的進(jìn)度。

在初始化 RelationBuilder 時(shí)，如果我們傳入了 constants，那么在調(diào)用 RelationBuilder#build! 時(shí)就會(huì)重建其中的全部關(guān)系，但是如果沒(méi)有傳入就會(huì)默認(rèn)加載 ActiveRecord 中所有的子類，并去掉其中包含 :: 的模型，也就是 ActiveRecord 中使用 has_and_belongs_to_many 創(chuàng)建的中間類，我們會(huì)在下一節(jié)中介紹如何單獨(dú)處理多對(duì)多關(guān)系：

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  

跟關(guān)系重建相關(guān)的代碼可以在 relation_builder.rb 找到完整的用于關(guān)系遷移的代碼。

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

通過(guò)這數(shù)據(jù)遷移和關(guān)系重建兩個(gè)步驟就已經(jīng)可以解決絕大部分的數(shù)據(jù)遷移問(wèn)題了，但是由于 MongoDB 和 ActiveRecord 中對(duì)于多對(duì)多關(guān)系的處理比較特殊，所以我們需要單獨(dú)進(jìn)行解決，如果所有的遷移問(wèn)題到這里都已經(jīng)解決了，那么我們就可以使用下面的遷移文件將數(shù)據(jù)庫(kù)中與 uuid 有關(guān)的全部列都刪除了：

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  

到這里位置整個(gè)遷移的過(guò)程就基本完成了，接下來(lái)就是跟整個(gè)遷移過(guò)程中有關(guān)的其它事項(xiàng)，例如：對(duì)多對(duì)關(guān)系、測(cè)試的重要性等話題。

多對(duì)多關(guān)系的處理

多對(duì)多關(guān)系在數(shù)據(jù)的遷移過(guò)程中其實(shí)稍微有一些復(fù)雜，在 Mongoid 中使用 has_and_belongs_to_many 會(huì)在相關(guān)的文檔下添加一個(gè) tag_ids 或者 post_ids 數(shù)組：

# The post document. 
 
{ 
 
“_id” : ObjectId(“4d3ed089fb60ab534684b7e9”), 
 
“tag_ids” : [ 
 
ObjectId(“4d3ed089fb60ab534684b7f2”), 
 
ObjectId(“4d3ed089fb60ab53468831f1”) 
 
], 
 
“title”: “xxx”, 
 
“content”: “xxx” 
 
}  

而 ActiveRecord 中會(huì)建立一張單獨(dú)的表，表的名稱是兩張表名按照字母表順序的拼接，如果是 Post 和 Tag，對(duì)應(yīng)的多對(duì)多表就是 posts_tags，除了創(chuàng)建多對(duì)多表，has_and_belongs_to_many 還會(huì)創(chuàng)建兩個(gè) ActiveRecord::Base的子類 Tag::HABTM_Posts 和 Post::HABTM_Tags，我們可以使用下面的代碼簡(jiǎn)單實(shí)驗(yàn)一下：

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  

上述代碼打印出了兩個(gè) has_and_belongs_to_many 生成的類 Tag::HABTM_Posts 和 Post::HABTM_Tags，它們有著完全相同的表 posts_tags，處理多對(duì)多關(guān)系時(shí)，我們只需要在使用 DatabaseTransformer 導(dǎo)入表中的所有的數(shù)據(jù)之后，再通過(guò)遍歷 posts_tags 表中的數(shù)據(jù)更新多對(duì)多的關(guān)系表就可以了：

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 的多對(duì)多關(guān)系都需要通過(guò)上述代碼進(jìn)行遷移，這一步需要在刪除數(shù)據(jù)庫(kù)中的所有 uuid 字段之前完成。

測(cè)試的重要性

在真正對(duì)線上的服務(wù)進(jìn)行停機(jī)遷移之前，我們其實(shí)需要對(duì)數(shù)據(jù)庫(kù)已有的數(shù)據(jù)進(jìn)行部分和全量測(cè)試，在部分測(cè)試階段，我們可以在本地準(zhǔn)備一個(gè)數(shù)據(jù)量為生產(chǎn)環(huán)境數(shù)據(jù)量 1/10 或者 1/100 的 MongoDB 數(shù)據(jù)庫(kù)，通過(guò)在本地模擬 MongoDB 和 MySQL 的環(huán)境進(jìn)行預(yù)遷移，確保我們能夠盡快地發(fā)現(xiàn)遷移腳本中的錯(cuò)誤。

準(zhǔn)備測(cè)試數(shù)據(jù)庫(kù)的辦法是通過(guò)關(guān)系刪除一些主要模型的數(shù)據(jù)行，在刪除時(shí)可以通過(guò) MongoDB 中的 dependent: :destroy 刪除相關(guān)的模型，這樣可以盡可能的保證數(shù)據(jù)的一致性和完整性，但是在對(duì)線上數(shù)據(jù)庫(kù)進(jìn)行遷移之前，我們依然需要對(duì) MongoDB 中的全部數(shù)據(jù)進(jìn)行全量的遷移測(cè)試，這樣可以發(fā)現(xiàn)一些更加隱蔽的問(wèn)題，保證真正上線時(shí)可以出現(xiàn)更少的狀況。

數(shù)據(jù)庫(kù)的遷移其實(shí)也屬于重構(gòu)，在進(jìn)行 MongoDB 的數(shù)據(jù)庫(kù)遷移之前一定要保證項(xiàng)目有著完善的測(cè)試體系和測(cè)試用例，這樣才能讓我們?cè)陧?xiàng)目重構(gòu)之后，確定不會(huì)出現(xiàn)我們難以預(yù)料的問(wèn)題，整個(gè)項(xiàng)目才是可控的，如果工程中沒(méi)有足夠的測(cè)試甚至沒(méi)有測(cè)試，那么就不要再說(shuō)重構(gòu)這件事情了 – 單元測(cè)試是重構(gòu)的基礎(chǔ)。

總結(jié)

如何從 MongoDB 遷移到 MySQL 其實(shí)是一個(gè)工程問(wèn)題，我們需要在整個(gè)過(guò)程中不斷尋找可能出錯(cuò)的問(wèn)題，將一個(gè)比較復(fù)雜的任務(wù)進(jìn)行拆分，在真正做遷移之前盡可能地減少遷移對(duì)服務(wù)可用性以及穩(wěn)定性帶來(lái)的影響。

除此之外，MongoDB 和 MySQL 之間的選擇也不一定是非此即彼，我們將項(xiàng)目中的大部分?jǐn)?shù)據(jù)都遷移到了 MySQL 中，但是將一部分用于計(jì)算和分析的數(shù)據(jù)留在了 MongoDB，這樣就可以保證 MongoDB 宕機(jī)之后仍然不會(huì)影響項(xiàng)目的主要任務(wù)，同時(shí)，MySQL 的備份和恢復(fù)速度也會(huì)因?yàn)閿?shù)據(jù)庫(kù)變小而非常迅速。

***一點(diǎn)，測(cè)試真的很重要，如果沒(méi)有測(cè)試，沒(méi)有人能夠做到在修改大量的業(yè)務(wù)代碼的過(guò)程中不丟失任何的業(yè)務(wù)邏輯，甚至如果沒(méi)有測(cè)試，很多業(yè)務(wù)邏輯可能在開(kāi)發(fā)的那一天就已經(jīng)丟失了。