某企業(yè)數(shù)據(jù)庫的跨國遷移

“連數(shù)據(jù)庫都上云了，還有什么不能上云？”亞馬遜的CTO Werner Vogels的這句話讓人印象深刻。在各種應(yīng)用向云遷移的過程中，數(shù)據(jù)庫的遷移應(yīng)該是最復(fù)雜和最能體現(xiàn)廠商技術(shù)和服務(wù)功底的。

數(shù)據(jù)庫遷移往往是企業(yè)上云之旅的重點和難點。為此，AWS推出了AWS Database Migration Service，并且已在中國區(qū)落地。

AWS Database Migration Service是一種Web服務(wù)，可用于將數(shù)據(jù)從本地數(shù)據(jù)庫、Amazon Relational Database Service （Amazon RDS）數(shù)據(jù)庫實例上的數(shù)據(jù)庫或 Amazon Elastic Compute Cloud （Amazon EC2）實例上的數(shù)據(jù)庫遷移到AWS服務(wù)上的數(shù)據(jù)庫。這些服務(wù)可以包括Amazon RDS上的數(shù)據(jù)庫或Amazon EC2實例上的數(shù)據(jù)庫。用戶還可以將數(shù)據(jù)庫從AWS服務(wù)遷移到本地數(shù)據(jù)庫，并可在異構(gòu)和同構(gòu)數(shù)據(jù)庫引擎之間遷移數(shù)據(jù)。

AWS DMS服務(wù)支持同構(gòu)遷移（例如從Oracle遷移到Oracle），以及在不同數(shù)據(jù)庫平臺之間的異構(gòu)遷移（例如從Oracle遷移到Amazon Aurora或從Microsoft SQL Server遷移到MySQL）。另外，它還支持客戶從任意受支持的源位置（包括Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle、SAP ASE和SQL Server）將數(shù)據(jù)流式傳輸?shù)紸mazon Redshift，以便在PB級數(shù)據(jù)倉庫中對數(shù)據(jù)進(jìn)行整合和輕松分析。AWS Database Migration Service 還可用于連續(xù)數(shù)據(jù)復(fù)制，且高度可用。

光環(huán)有云利用AWS DMS將某企業(yè)客戶的MySQL遷移至AWS RDS Aurora。該用戶的業(yè)務(wù)系統(tǒng)原來運行在某云新加坡區(qū)域，因故需要遷移到其他公有云。最終，客戶選擇將其業(yè)務(wù)系統(tǒng)遷移至AWS東京區(qū)域，同時選擇AWS高級咨詢合作伙伴——光環(huán)有云作為咨詢和實施服務(wù)提供商，完成AWS基礎(chǔ)架構(gòu)的部署和數(shù)據(jù)庫遷移工作。

客戶運營著一套類金融系統(tǒng)，由10+應(yīng)用系統(tǒng)構(gòu)成，超過40臺虛擬服務(wù)器，采用MySQL 5.6數(shù)據(jù)庫服務(wù)，數(shù)據(jù)量超過700GB+，日數(shù)據(jù)新增量約5GB，另有一個測試數(shù)據(jù)庫?？蛻糁饕\營的業(yè)務(wù)系統(tǒng)對于安全性要求很高，出于業(yè)務(wù)連續(xù)考慮，預(yù)設(shè)遷移時間窗口有限，其業(yè)務(wù)系統(tǒng)依賴于事務(wù)處理，對延遲敏感。

光環(huán)有云利用AWS DMS將客戶的MySQL遷移至AWS Aurora的具體過程如下。

第一，數(shù)據(jù)庫遷移準(zhǔn)備。

數(shù)據(jù)庫信息準(zhǔn)備工作包括生產(chǎn)庫信息統(tǒng)計、生產(chǎn)庫性能監(jiān)控、日新增數(shù)據(jù)量統(tǒng)計、業(yè)務(wù)高峰期統(tǒng)計，以及生產(chǎn)數(shù)據(jù)庫版本、參數(shù)、用戶、存儲過程、函數(shù)等信息記錄。

在進(jìn)行方案規(guī)劃時，通過對客戶業(yè)務(wù)場景、應(yīng)用系統(tǒng)、數(shù)據(jù)庫以及運營管理等多方面深入調(diào)研后，基于AWS數(shù)據(jù)遷移最佳實踐和光環(huán)有云在數(shù)據(jù)庫遷移的豐富經(jīng)驗，結(jié)合客戶的具體需求和約束條件，提出了以MySQL復(fù)制+DMS同步和以MySQL主從復(fù)制+xtrabackup 增量還原兩個方案規(guī)劃。

MySQL主從復(fù)制+DMS同步方案，其主要步驟如下：搭建IPsec VPN，打通某云Singapore—AWS Tokyo；某云RDS創(chuàng)建物理全量備份，并將備份文件還原到一臺新實例中，該實例將當(dāng)做此次測試的Master庫；在AWS環(huán)境中，新啟一臺EC2實例并安裝MySQL服務(wù)，同時拉取備份文件到EC2實例中；將EC2中的備份文件還原到EC2 MySQL數(shù)據(jù)庫里，當(dāng)前MySQL將充當(dāng)Slave服務(wù)器；在Master和Slave 之間建立主從復(fù)制；AWS Tokyo region的VPC中啟動一臺Aurora MySQL-5.6；在EC2 MySQL（Slave）和AWS RDS Aurora 之間配置DMS同步；等Master、Slave與AWS RDS Aurora同步完成后，校驗數(shù)據(jù)完整性；導(dǎo)入一批測試數(shù)據(jù)到Master中，用作增量數(shù)據(jù)同步測試；校驗Master、Slave與AWS RDS Aurora同步情況，并校驗數(shù)據(jù)完整性。

MySQL主從復(fù)制+xtrabackup增量還原方案，其主要步驟如下：搭建IPsec VPN，打通某云Singapore—AWS Tokyo；某云RDS創(chuàng)建物理全量備份，并將備份文件還原到一臺新實例中，該實例將當(dāng)做此次測試的Master庫；AWS環(huán)境中，新啟一臺EC2實例，安裝MySQL服務(wù)，拉取備份文件到實例中；將EC2中的備份文件還原到EC2 MySQL數(shù)據(jù)庫里，當(dāng)前MySQL將充當(dāng)Slave服務(wù)器；在Master和Slave 之間建立主從復(fù)制；在Slave中使用xtrabackup創(chuàng)建全備；將全備文件同步到一個AWS Tokyo region的S3存儲桶A中；導(dǎo)入一批測試數(shù)據(jù)到Master中，用作增量數(shù)據(jù)同步測試；在Slave中在全備的基礎(chǔ)上使用xtrabackup創(chuàng)建增量備份；使用AWS S3 Sync將增量數(shù)據(jù)同步到S3存儲桶A中；將AWS Tokyo region 的S3存儲桶A中的所有數(shù)據(jù)，還原到AWS RDS Aurora數(shù)據(jù)庫中。

在遷移前，以較小數(shù)據(jù)量按照規(guī)劃中的兩種方案分別進(jìn)行了模擬測試。測試結(jié)論顯示，鑒于客戶預(yù)設(shè)停機窗口有限，為保持良好的業(yè)務(wù)持續(xù)性，所以最終選擇方案1作為主方案，方案2作為備用方案。在遷移實施時，兩個方案同時進(jìn)行。

第二，項目實施遷移。

遷移原則如下：滿足遷移約束條件，方案驗證可行；對遷移過程控制和識別風(fēng)險并應(yīng)對；業(yè)務(wù)影響最小，數(shù)據(jù)安全、完整、可用；最小可用權(quán)限，授權(quán)操作，不碰數(shù)據(jù)。

“結(jié)果很重要，過程須控制?！边w移是一件多風(fēng)險、易出錯的工作，協(xié)同工作的所有環(huán)節(jié)都可能出現(xiàn)錯誤，從而導(dǎo)致遷移的失敗。光環(huán)有云對遷移過程十分重視，會同客戶一起認(rèn)真分析遷移的所有流程，并細(xì)化成指導(dǎo)遷移實施的指導(dǎo)性文檔，作為遷移實施的過程控制文檔，其中包括遷移詳細(xì)計劃、遷移流程、所有任務(wù)、RACI協(xié)作、任務(wù)詳細(xì)文檔（腳本、操作詳細(xì)步驟）、任務(wù)耗時、任務(wù)異常處理等。

在使用AWS DMS進(jìn)行遷移的過程中，可能會遇到如下挑戰(zhàn)：數(shù)據(jù)庫權(quán)限、目標(biāo)庫信息重建（用戶、存儲過程、視圖、函數(shù)等）、DMS校驗報錯、字符集不一致、時區(qū)設(shè)置、DMS同步數(shù)據(jù)追平、DMS實例與遷移數(shù)據(jù)量、增量與時間窗口的平衡。

在實踐中，光環(huán)有云發(fā)現(xiàn)使用AWS DMS進(jìn)行遷移既有優(yōu)勢，也有其局限性。優(yōu)勢表現(xiàn)在：簡單易用；在遷移過程中源數(shù)據(jù)庫可持續(xù)運行；具有較小的業(yè)務(wù)中斷窗口，可保持業(yè)務(wù)連續(xù)性；支持異構(gòu)數(shù)據(jù)庫遷移；可實現(xiàn)自動故障轉(zhuǎn)移，十分可靠；在向Aurora遷移數(shù)據(jù)庫時，可免費使用AWS DMS 特定實例 6個月。

其局限性表現(xiàn)在：DMS僅同步表中的數(shù)據(jù)；同步較大的數(shù)據(jù)增量時，耗時較長；AWS DMS自身校驗機制耗時易報錯。

總之，利用AWS DMS進(jìn)行數(shù)據(jù)庫遷移，可以輕松并安全地將數(shù)據(jù)庫遷移至AWS。源數(shù)據(jù)庫能夠在遷移過程中全面保持運行，從而盡可能減少依賴該數(shù)據(jù)庫的應(yīng)用程序的停機時間。AWS DMS可以在廣泛使用的開源商業(yè)數(shù)據(jù)庫之間遷移數(shù)據(jù)。不過還是要提醒用戶注意，數(shù)據(jù)庫遷移是一項十分復(fù)雜且有難度的工作，即使是有高效安全的遷移工具，還是需要一支有經(jīng)驗的技術(shù)團(tuán)隊作為遷移的支持，這樣才能保證數(shù)據(jù)庫遷移的安全、有序進(jìn)行，避免差錯。光環(huán)有云作為AWS專業(yè)服務(wù)商，可以為客戶提供從云遷移到運維管理的整套解決方案。