簡述
SQL Server 是一個值得信賴的老牌資料庫系統，自從 1988 年由 Microsoft、Sybase 和 Ashton-Tate 三家公司共同推出之后就一直不斷迭代更新，而如今我們提到 SQL Server 通常是指 Microsoft 從 SQL Server 2000 之后的版本，至今 SQL Server 家族已經非常繁茂涵蓋了 云上（Azure SQL Server）、IoT 設備（邊緣 SQL Server）、以及經典版本（本地 SQL Server），
實作 SQL Server 作為源端的實時資料同步，一般都會用到它的 CDC 功能，這個功能是從 2008 版本才開始支持，因此本文主要也是基于 SQL Server 2008 版本介紹如何使用 CloudCanal 快速構建一條穩定高效運行的 SQL Server 到 MySQL 資料同步鏈路，
技術點
基于 SQL Server 的 CDC
SQL Server 將用戶的每一個資料操作都記錄在后綴為 ldf 日志檔案中，這些日志會保存在 ldf 檔案中，當資料庫啟用 CDC 能力后，SQL Server 代理上會生成一個專門分析ldf檔案的作業，再將具體的表啟用 CDC, 則該作業開始持續分析檔案中的變更事件到指定的表中，
作業執行用到 SQL Server 代理，該組件如果處于非啟動狀態，則生成任何可消費的變更資料，通常，我們可以在 Windows 物件資源管理器中查看是否已經開啟了 SQL Server 代理，
由于 SQL Server 執行作業時無法設定起始位置，因此對于一個表的變更記錄我們最早只能追溯到表啟用 CDC 的那個時間點，具體的起始位點可以在 “cdc.change_tables” 表中查詢得到，
還需要注意的另外一個細節是 CDC 表也是一張普通的表它和用戶共享同一個資料空間，為了防止 CDC 表資料無限膨脹 SQL Server 會每天定時執行清理作業，清理過期的資料（具體時間視資料庫配置而定），
SQL Server -> MySQL 的資料型別支持
CloudCanal 從 2021 年開始支持 SQL Server 同步后就不斷地豐富它的對端資料源，支持 SQL Server 到 MySQL 是一個非常重要的同步鏈路，
目前 CloudCanal 已經可以支持的型別和映射關系如下：
| SQL Server 型別 | MySQL 型別 | 備注 |
|---|---|---|
| BIT | BIT | |
| DECIMAL | DECIMAL | |
| NUMERIC | DECIMAL | |
| SMALLINT | SMALLINT | |
| TINYINT | TINYINT | 映射為 tinyint unsigned? |
| INT | INT | |
| BIGINT | BIGINT | |
| SMALLMONEY | FLOAT | |
| MONEY | FLOAT | |
| FLOAT | FLOAT | |
| REAL | DOUBLE | |
| DATE | DATE | |
| DATETIMEOFFSET | DATETIME | 由于 MySQL 型別限制，會丟棄時區資訊同時最多保留 6 位精度 |
| DATETIME2 | DATETIME | 由于 MySQL 型別限制，會保留最多 6 位精度 |
| SMALLDATETIME | DATETIME | |
| DATETIME | DATETIME | 由于 MySQL 型別限制，會保留最多 6 位精度 |
| TIME | TIME | 由于 MySQL 型別限制，會保留最多 6 位精度 |
| CHAR | CHAR | ? |
| VARCHAR | VARCHAR | 源端 SQL Server 如果為 VARCHAR(MAX)，則按照 TEXT 來處理 |
| TEXT | TEXT | |
| NCHAR | CHAR | |
| NVARCHAR | VARCHAR | 源端 SQL Server 如果為 NVARCHAR(MAX)，則按照 NTEXT? 來處理 |
| NTEXT | TEXT | |
| BINARY | BINARY | |
| VARBINARY | VARBINARY | 源端 SQL Server 如果為 VARBINARY(MAX)，則按照 IMAGE? 來處理 |
| IMAGE | BLOB | |
| TIMESTAMP | BIGINT | 會映射為 bigint unsigned |
| ROWVERSION | BIGINT | 會映射為 bigint unsigned |
| HIERARCHYID | -- | 暫不支持 |
| UNIQUEIDENTIFIER | VARCHAR(36) | |
| SQL_VARIANT | -- | 暫不支持 |
| XML | TEXT | |
| GEOMETRY | -- | 暫不支持 |
| GEOGRAPHY | -- | 暫不支持 |
| SYSNAME | VARCHAR(128) |
操作示例
前置條件
- 登陸 CloudCanal SaaS版，使用參見快速上手檔案
- 準備一個 SQL Server 資料庫，和 MySQL 實體（本例分別使用自建 SQL Server 2008 和 MySQL 8.0）
- 登錄 CloudCanal 平臺 ，添加 SQL Server 和 MySQL
- 創建一條 SQL Server -> MySQL 鏈路作為增量資料來源
任務創建
- 任務管理-> 任務創建
- 測驗鏈接并選擇 源 和 目標 資料庫
- 點擊下一步
- 選擇 資料同步，并勾選 全量資料初始化，其他選項默認
- 此時如果 SQL Server 上資料庫還沒有啟用 CDC 功能，則會在點擊下一步的時候提示如何啟用 CDC，只要按照提示的參考陳述句執行即可，
- 選擇需要遷移同步的表和列
- 確認創建任務
- 任務自動做結構遷移、全量遷移、增量同步
校驗資料
- 程式造資料， SQL Server -> MySQL，在源端以 1:1:1 的比例隨機執行Insert、Update、Delete三種型別陳述句，使用20個執行緒并發寫入變更，
- 任務正常運行一段時間后，停止造資料
- 點擊 SQLServer -> MySQL 任務詳情，功能串列 -> 創建相似任務，在創建任務的第二步選擇資料校驗
- 資料校驗 OK
- 下面這個是校驗結果，如果我們對端和源端一旦出現資料不一致就會像下面這樣非常醒目的提示給用戶，有多少資料不一致，有多少資料丟失，
常見問題
支持什么版本的 SQL Server 和 MySQL ？
- 目前源端 SQL Server 2008 及以上版本皆可使用 CloudCanal 進行遷移同步（推薦使用 SQL Server 2016 或 SQL Server 2008）
- 對端 MySQL 支持 5.6、5.7、8.0 版本，也可以選用 阿里云 RDS for MySQL 對應的版本，或者其它云服務商的 MySQL 版本
資料不同步了都有哪些情況？
- SQL Server CDC 需要依賴 SQL Server 代理，首先要確定 SQL Server 代理服務是否啟動
- 表在啟動 CDC 的時候會確定要捕獲的列清單，此時如果修改列的型別可能會導致 CDC 中斷，目前解決辦法只能重建任務，
- 增/減 同一個列名的列，對一個列洗掉后在增加，雖然 CDC 表中欄位依然存在但是也會導致整個 CDC 中斷，
什么情況下會影響穩定的資料同步？
- 如果任務在同步期間出現了例外導致任務延遲，這時候需要格外注意，如果過長時間的延遲，即便是修復了延遲的問題（比如對端資料庫長時間出現不可用）在后續資料同步上也可能存在丟失資料的風險，
- SQL Server 為了防止 CDC 表資料無限膨脹 SQL Server 會每天定時執行清理作業，清理超過 3天的資料，
- 為了增加延遲的容忍度可以執行這條 SQL 來增加 CDC 資料的保存時間，代價是這些資料需要存放到資料庫表中，如果每日資料變更很多對磁盤開銷會有額外的要求，
- execute sys.sp_cdc_change_job @job_type = n'cleanup', @retention = 4320
- msdb.dbo.cdc_jobs 表中保存了具體 捕獲任務的資料保存時間，
總結
本文簡單介紹了如何使用 CloudCanal 進行 SQL Server -> MySQL 資料遷移同步，各位讀者朋友，如果你覺得還不錯，請點贊、評論加轉發吧，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/537755.html
標籤：其他
下一篇：mysql hint介紹