在數字化轉型浪潮席捲各行各業的今天，數據已成為企業的核心資產。而數據庫作為數據的承載基石，其性能、可擴展性、穩定性和成本效益，直接關係到企業業務的敏捷性與未來發展。許多企業最初選擇開源MySQL數據庫，是因其簡單易用、生態豐富而備受青睞，但隨着業務規模的飛速擴張，MySQL在面臨海量數據、高併發事務及分佈式部署等場景時，常常在擴展性、容災能力和運營成本上遇到瓶頸。
OceanBase 作為原生分佈式數據庫，憑藉其強大的水平擴展能力、金融級高可用性（RPO=0，RTO<30秒）、高度兼容MySQL協議以及優異的成本控制優勢，成為企業數據庫升級換代、應對未來挑戰的理想選擇。將數據從MySQL遷移至OceanBase，不僅是數據庫平台的更替，更是一次架構的現代化演進，旨在為企業的核心業務系統注入新的活力，構建堅實、彈性的數據底座。
然而，數據庫遷移並非簡單的“數據搬家”，是涉及評估、設計、實施、驗證等多個環節的系統性工程，本文結合實戰項目經驗，梳理從 MySQL 遷移至 OceanBase 4254 版本的全流程實操方案，幫你規避數據的遷移之坑！
版本信息
- OceanBase版本:4254
- Mysql版本：5.7/8.0
- OMS工具：425BP1/431
- OCP：425
需求分析和規劃
源庫深度分析
源實例信息
連接信息：域名/IP + 端口。
版本：mysql5.6/5.7以及mysql8.0，不同版本默認字符集字符序和部分變量參數值可能存在不同。
源實例資源佔用情況：CPU、內存
數據類型及數據量
- 統計數據類型以及使用的字符集類別，評估在 OceanBase 的兼容性。
- 統計數據庫、表的總數量，以及總數據量（GB/TB級別）；這決定了遷移時間和資源需求。
JDBC驅動版本
切換OB後可以使用OB提供的jdbc驅動，也可以使用mysql原生驅動，如使用後者：
- 對於Mysql Connector/J5.x版本，推薦使用5.1.40-5.1.49之間的版本。
- 對於Mysql Connector/J8.x版本，推薦使用8.0.7-8.0.25以及8.2.0-8.4.0之間的版本。
Mysql原生驅動和OB數據庫不一定能完全兼容，V8版本不推薦使用8.0.26-8.0.33這個區間的版本，有項目case案例，介於使用場景不同，非100%復現。
連接串可沿用原來的，適當加上參數useLocalSessionState=true&tinyInt=false,如使用V8遇到兼容性問題可嘗試添加compatibleMysqlVersion=8參數測試能否規避。
對象分析
梳理需遷移的對象（包括庫、表、視圖、觸發器、主外鍵約束、存儲過程、函數等）。注意 OceanBase 對 MySQL 語法的兼容性，但並非 100% 兼容。
注意事項：（使用OMS工具遷移）
1、對於無主鍵或者非空唯一鍵，主要影響有兩個：
- 無法做反向同步(未在OBMysql業務租户創建__oceanbase_inner_drc_user情況下)
OBMysql->Mysql，不支持無主鍵或者非空唯一鍵表的遷移。 - 無法做全量校驗
在Mysql->OBMysql,無法做全量或者增量校驗。所以對於這部分表需要評估對業務重要性程度進行改造。
-- 查找無主鍵或者非空唯一鍵的表
select table_schema,table_name
from information_schema.tables b
where table_schema=database()
and not exists(
select 1
from (
select distinct table_name,table_schema
from information_statistics where table_schema=database()
group by table_schema,table_name,index_name
having count(*)=count(
if(upper(nullable) !='YES'
and non_unique=0,1,null)))a
where b.table_schema=a.table_schema
and b.table_name=a.table_name);2、OMS無法遷移check約束和非noaction屬性的外鍵，需要找出來在正向切換停機窗口補上。
-- 找出check和外鍵約束
select constraint_schema,
constraint_name,
table_name,
constraint_type
from information_schema.table_constraints
where constraint_schema=database()
and constraint_type in('FOREIGN KEY','CHECK');
-- 找出非no action屬性的外鍵
select constraint_schema,
constraint_name,
table_name,
referenced_table_name,
update_rule,
delete_rule
from information.referential_constraints
where constraint_schema=database()
and (update_rule !='NO ACTION' or delete_rule!='NO ACTION');變量參數
-- 字符集確認
show variables like '%character%';
show global variables like '%character%';
-- 字符序（不同字符序可能會導致查詢結果不同）
show variables like '%collation%';
show global variables like '%collation%';
--sql_mode SQL模式檢查
show variables like '%sql_mode%';
show global variables like '%sql_mode%';
注意：列舉以上比較關鍵的變量值，其中sql_mode在
mysql5.6:
mysql5.7:ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
mysql8默認值為:ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION
OB42版本默認值為:STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER
可以看出OB42X版本對於SQL模式限制相對寬鬆，因此建議OB42X SQL_MODE為：ONLY_FULL_GROUP_BY, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER增量日誌檢查
增量遷移需確保源端Mysql開啓binlog，需滿足binlog_row_image為full,binlog_format=row,且至少保留24小時以上（建議3天以上）；
性能基線
記錄關鍵業務查詢的 QPS、TPS 和延遲，作為遷移後性能對比的基準。
遷移用户創建
1、創建數據遷移用户omsmgr並授予相應的權限;
-- 創建用户
create user `omsmgr`@`%` identified by ****;
-- 授予遷移數據庫的讀權限
grant select on .* to 'omsmgr';
grant show view on .* to 'omsmgr';-- 如果是mysql8.0版本需要授予show view的權限
-- 增量遷移場景下，需要具備replication_client、replication_slave和select *.*權限
grant replication_client,replication_slave on *.* to 'omsmgr' [with grant option];
grant select on *.* to 'omsmgr';
-- 反向增量（OB->Mysql）需要授予相應的DML和DDL權限
grant update,delete,insert on .* to 'omsmgr'; -- dml
grant alter,create,create view,drop,index on .* to 'omsmgr'; -- ddl
⚠️：如果勾選了 增量同步時，允許 OMS 自動向該實例寫入心跳數據，以解決源端在無業務寫入場景下的高延時問題，並且填寫的數據庫用户具備創建表、寫表的權限，OceanBase 遷移服務（OceanBase Migration Service，OMS）會向對應的數據庫中創建心跳錶，並以 5 秒/次的頻率更新心跳錶。
CREATE DATABASE IF NOT EXISTS drc;
GRANT CREATE ON drc.heartbeat TO 'omsmgr';
CREATE TABLE IF NOT EXISTS drc.heartbeat (`id` smallint(6) NOT NULL DEFAULT 1,`ts` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB comment='心跳錶';
GRANT CREATE ON drc.heartbeat TO 'omsmgr';
GRANT INSERT, UPDATE, DELETE ON drc.heartbeat TO 'omsmgr';
部分場景下OMS會識別不到源端給予遷移用户對錶drc.heartbeat的DML權限，因此可將授權語句改成drc.*
GRANT INSERT, UPDATE, DELETE ON drc.* TO 'omsmgr';網絡檢查
本文介紹的是通過OMS工具遷移Mysql數據到Ocebase數據庫，所以需要確保OMS所在的服務器能訪問源端mysql實例；需要開通訪問源實例的域名/IP+端口；
上下游數據源確認
待遷移數據庫的數據除了應用業務本身的讀寫，是否還存在上下游數據來源，上游如通過OGG或者DTS等遷移到mysql數據庫，以及下游是否存在往該庫抽取數據的情況。如存在後續切換到OB後，上下游的目標庫也需要相應的切到OB。
目標庫規劃設計
集羣架構選型
相比Oracle而言，跑在Mysql實例上的業務系統相對輕量，因此一個 OceanBase 集羣可用承載多個輕量的mysql實例。4F1A雙活架構（兩地三中心）因具備高可用、高容災能力可作為參考選型架構（具體可參考實際項目需求和POC測試情況，本架構在筆者所在項目經過綜合方面考慮選定）。
租户配置
參數配置
創建租户需要指定租户字符集、字符序以及部分變量值設置如sql_mode等影響結果集等關鍵變量。因此可關注《源庫分析-變量參數》，根據源庫的使用情況再配置響應的變量值。另外源mysql主鍵一般自增列int類型，在OB存在自增列跳變的情況（如副本切主、唯一鍵衝突、事務回滾、宕機重啓、自增cache失效），如果同樣設置為int類型，跳變情況下容易拉暴自增列的值，因此可以將int改為bigint或者將自增列緩存個數變量（auto_increment_cache_size）的值調小（默認為100萬），可調整10萬以內。
為避免夏令營時區問題，可將時區變量time_zone設置為Asia/Shanghai，其默認值為+8:00。
關於sql_mode：
mysql5.6:
mysql5.7:ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTIONmysql8默認值為:
ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTIONOB42版本默認值為:
STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER可以看出OB42X版本對於SQL模式限制相對寬鬆，因此建議OB42X SQL_MODE為： ONLY_FULL_GROUP_BY, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER
資源配置
大部分傳統數據都是運行在非信創服務器上，而信創不光是數據庫產品，而是涉及整個系統鏈路。所以需要考慮信創服務器和非信創服務器在CPU 算力上的差距；壓力測試階段CPU可按1:1.5，1:2遞增測試實際所需資源。內存需保持大於等於源內存。
數據庫配置
創建數據庫並指定字符集和字符序，根據源端使用情況而定。需要結合表的字符集和字符序情況，在mysql可能經歷過5.6/5.7->8.0升級的情況，Mysql5X版本默認字符序為utf8mb4_general_ci，Mysql8.0默認為utf8mb4_0900_ai_ci,因此有必要確認好業務常用的字符序。
用户配置
根據源端業務用户使用情況進行創建和授權。在切換前，除了遷移用户和root用户，其他用户一律給只讀權限，避免在割接期間誤操作帶來的數據一致性問題。
目標段除了配置業務用户以為，還需要遷移用户，可直接使用root用户或者創建遷移用户並給予所需的權限。具體權限可參考《源庫分析-遷移用户創建》反向增量時所需的權限。
此外，反向增量需要以oceanbase作為源，因此需要在OB端的SYS租户和業務租户創建相應的用户。
-- SYS租户下創建（當使用 OceanBase 數據源作為源端進行結構遷移、結構同步或增量同步時，以及使用 OceanBase 數據源作為目標端進行反向增量時需要創建drc_user用户）
CREATE USER drc_user IDENTIFIED BY '';
GRANT SELECT ON *.* TO drc_user;
-- 業務租户下創建（可選）：該用户為可選用户，僅在需要遷移無唯一鍵表時創建
CREATE USER __oceanbase_inner_drc_user IDENTIFIED BY '';
GRANT SELECT ON *.* TO __oceanbase_inner_drc_user;副本策略配置
建議將業務租户主副本落在同機房的一個或者多個zone上，輕量級可設置單zone，具體看資源消耗情況。
遷移用户創建
源端遷移用户創建
-- 創建用户
create user `omsmgr`@`%` identified by ****;
-- 授予遷移數據庫的讀權限
grant select on .* to 'omsmgr';
grant show view on .* to 'omsmgr';-- 如果是mysql8.0版本需要授予show view的權限
-- 增量遷移場景下，需要具備replication_client、replication_slave和select *.*權限
grant replication_client,replication_slave on *.* to 'omsmgr' [with grant option];
grant select on *.* to 'omsmgr';
-- 反向增量（OB->Mysql）需要授予相應的DML和DDL權限
grant update,delete,insert on .* to 'omsmgr'; -- dml
grant alter,create,create view,drop,truncate,rename,index on .* to 'omsmgr'; -- ddl
⚠️：如果勾選了 增量同步時，允許 OMS 自動向該實例寫入心跳數據，以解決源端在無業務寫入場景下的高延時問題，並且填寫的數據庫用户具備創建表、寫表的權限，OceanBase 遷移服務（OceanBase Migration Service，OMS）會向對應的數據庫中創建心跳錶，並以 5 秒/次的頻率更新心跳錶。
CREATE DATABASE IF NOT EXISTS drc;
GRANT CREATE ON drc.heartbeat TO 'omsmgr';
CREATE TABLE IF NOT EXISTS drc.heartbeat (`id` smallint(6) NOT NULL DEFAULT 1,`ts` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB comment='心跳錶';
GRANT CREATE ON drc.heartbeat TO 'omsmgr';
GRANT INSERT, UPDATE, DELETE ON drc.heartbeat TO 'omsmgr';
部分場景下OMS會識別不到源端給予遷移用户對錶drc.heartbeat的DML權限，因此可將授權語句改成drc.*
GRANT INSERT, UPDATE, DELETE ON drc.* TO 'omsmgr';目標端遷移用户創建
-- 創建用户
create user `omsmgr`@`%` identified by ****;
-- 授予用户相應的讀寫權限
grant update,delete,insert on .* to 'omsmgr'; -- dml
grant alter,create,create view,drop,truncate,rename,index on .* to 'omsmgr'; -- ddl
-- SYS租户下創建（當使用 OceanBase 數據源作為源端進行結構遷移、結構同步或增量同步時，以及使用 OceanBase 數據源作為目標端進行反向增量時需要創建drc_user用户）
CREATE USER drc_user IDENTIFIED BY '';
GRANT SELECT ON *.* TO drc_user;
-- 業務租户下創建（可選）：該用户為可選用户，僅在需要遷移無唯一鍵表時創建
CREATE USER __oceanbase_inner_drc_user IDENTIFIED BY '';
GRANT SELECT ON *.* TO __oceanbase_inner_drc_user;遷移規劃
如果都是數據量比較小的庫，建議創建單個鏈路進行。如果數據量比較大，可按如下規則拆分：
按數據類型區分：LOB和非LOB數據
- 冷熱數據：日誌表歷史數據、業務流水錶歷史數據
- 數據量規模：大表和小表，以億級別為分水嶺
- 業務模塊：按業務模塊劃分鏈路（部分會按schema劃分模塊）
- OMS均衡：多個OMS節點負載均衡（多節點/多台單節點）
遷移步驟
OB端數據庫創建
-- 在源實例查找數據庫清單並確認要創建的業務數據庫
show database;OB端業務用户創建及授權
-- 在源實例導出業務用户及權限然後在OB端執行
show grants for user_a;
注意：在割接前，除root和遷移用户以外的所有用户只授予只讀權限。OMS數據源配置
配置Mysql數據源
登錄OMS界面->
單擊左側數據源管理->
新建數據源->
數據庫類型(選擇Mysql)->
數據庫屬性選擇（默認主庫）->
IP/端口/用户名/密碼等按實際環境信息填寫。
配置OceanBase Mysql租户數據源
登錄OMS界面->
單擊左側數據源管理->
新建數據源->
數據庫類型(選擇OceanBase )->
租户類型（選擇Mysql)->
IP/端口/租户名/集羣名/用户名/密碼等按實際環境信息填寫
創建遷移鏈路
創建全量遷移鏈路
登錄OMS界面->
數據遷移->
新建遷移項目(定義名稱、源端、目標端)->
遷移選項（結構遷移+全量遷移+全量校驗）->
遷移對象：
- 1、指定對象:根據已經顯示的進行勾選
- 2、匹配規則：按照SCHAME.TABLE_NAME格式匹配，若想改變目標表名稱可以SCHAME.TABLE_NAME=SCHAME.NEW_TABLE_NAME進行匹配,需要點擊校驗和預覽對象確認->
遷移選項：
- 1、全量遷移/增量遷移/全量校驗：可自定義資源根據機器資源及規劃鏈路數酌情分配，後續亦可調整。
- 2、遷移高級配置：不做任何處理。
- 3、處理策略為停止遷移，允許索引後置。
- 4、增量記錄保存時間：根據實際需求，無則默認120小時即可->
預檢查通過後，啓動項目。
創建增量遷移鏈路
登錄OMS界面->
數據遷移->
新建遷移項目(定義名稱、源端、目標端)->
遷移選項（增量遷移:根據實際需求勾選DML/DDL+全量校驗）->
遷移對象：
- 1、指定對象:根據已經顯示的進行勾選
- 2、匹配規則：按照SCHAME.TABLE_NAME格式匹配，若想改變目標表名稱可以SCHAME.TABLE_NAME=SCHAME.NEW_TABLE_NAME進行匹配,需要點擊校驗和預覽對象確認）->
遷移選項：
- 1、全量遷移/全量校驗：可自定義資源根據機器資源及規劃鏈路數酌情分配，後續亦可調整。
- 2、遷移高級配置：不做任何處理。
- 3、處理策略為停止遷移，允許索引後置）->
預檢查通過後，啓動項目
其他數據對象遷移
OMS430版本開始支持遷移除表和視圖意外的其他數據庫對象。也可以通過DBCAT轉換成obmysql支持的語法，再進行批量執行。
創建鏈路檢驗數據
OMS430版本開始支持配置全量檢驗、行數校驗、增量校驗。
應用切換
源端停寫
源端對業務用户進行鎖定和kill相應的活躍會話，或者只授予只讀權限。並授予遷移用户omsmgr相應的讀寫權限。
注意：部分mysql實例業務用途範圍可能比較廣泛，在源MYSQL實例用户權限變更前需要做評審和複合，避免有生產影響。
數據校驗
對原有的增量遷移鏈路上執行正向切換，停止該鏈路。停止後OMS上發起全量或者增量數據校驗，確保數據一致性後。如果全量校驗時間較長，可在切換前先做全量校驗，源端停寫後再拉增量校驗，減少應用停服時間。
源端禁用外鍵+觸發器（如有）
源端啓用外鍵和觸發器
目標端啓用外鍵+觸發器（如有）
目標端啓用外鍵和觸發器
創建反向增量鏈路
可參考《創建增量遷移鏈路》，注意這時的源為oceanbase，目標端為mysql。
反向增量鏈路創建後，原有OB端只有只讀權限，這時可以放開所有業務用户的讀寫權限。
應用切換
應用切換鏈接到OB端
應用驗證
功能、性能、用户權限等方面測試。
注意事項
字符序
1、mysql8.0->OB過程中，如果兩邊字符序不一致，在增量的create同步過程中，會按照各自默認的字符序進行表的創建，因此需要注意增量產生的新表的字符序問題。
2、在OB mysql租户模式下，字符序utf8mb4_0900_ai_ci和utf8mb4_general_ci是衝突的，即兩表關聯，且各自對應以上字符序時會報Illegal mix of collations(utf8mb4_0900_ai_ci,IMPLICIT),(utf8mb4_general_ci,IMPLICIT)-invalid query。需要將兩表字符序設置為一致。
字符集導致的數據校驗問題
1、由於 OB 默認字符集為utf8mb4，且不支持utfmb3。因此如果源mysql實例字符集為utfmb3，在反向同步的時如有特殊符號是mb3不支持的，可能會造成兩邊的數據不一致。
2、特殊符號在OB能正常顯示，但是在源mysql會顯示亂碼或者？。這部分理論是符合預期的，説明源mysql在之前就是這樣存儲特殊符號的。因此可忽略這部分不一致的數據問題。
如果你在實際操作中遇到問題，或是有獨到的優化經驗，歡迎在評論區留言分享，下次見！
更多技術分享可掃碼關注查看
