DRS界面信息重疊是什么原因
DRS界面出現信息重疊通常是頁面縮放率過小導致的,建議將頁面縮放率調整為100%即可顯示正常。
目標庫讀寫設置是實例級還是庫級
配置遷移任務時,目標數據庫實例可以選擇設置為“只讀”或者“讀寫”狀態。
- 只讀:目標數據庫整個實例將轉化為只讀、不可寫入的狀態,遷移任務結束后恢復可讀寫狀態,此選項可有效的確保數據遷移的完整性和成功率,推薦此選項。
- 讀寫:目標數據庫可以讀寫,但需要避免操作或接入應用后會更改遷移中的數據(注意:無業務的程序常常也有微量的數據操作),進而形成數據沖突、任務故障、且無法修復續傳,充分了解要點后可選擇此選項。
只讀保護優點是避免用戶對正在遷移的數據庫或表進行DDL或DML誤操作,造成數據不一致,可提高遷移完整性和數據一致性。
- 任務啟動后,DRS不支持修改目標數據庫狀態。
- 待所有設置該目標庫為“只讀”狀態的遷移任務結束后,可恢復讀寫。
MySQL源庫設置了global binlog_format = ROW沒有立即生效
使用DRS進行MySQL的遷移時,必須確保源庫的binlog_format是ROW格式的,否則就會導致任務失敗甚至數據丟失。在源庫設置了global級別的binlog_format=ROW之后,還需要中斷之前所有的業務連接,因為設置之前的連接使用的還是非ROW格式的binlog寫入。
安全設置global級binlog_format=ROW的步驟
步驟 1 通過MySQL官方客戶端或者其它工具登錄源數據庫。
步驟 2 在源數據庫上執行全局參數設置命令。
set global binlog_format = ROW;
步驟 3 在源數據庫上執行如下命令確認上面操作已執行成功。
select @@global.binlog_format;
步驟 4 您可以通過如下兩種方式確保修改后的源庫binlog_format格式立即生效。
方法一:
- 選擇一個非業務的時間段,中斷當前數據庫上的所有業務連接。
a. 通過如下命令查詢當前數據庫上的所有業務連接(所有的binlog Dump連接及當前連接除外)。
show processlist;
b. 中斷上面查出的所有業務連接。

- 為了避免源庫binlog_format格式因為數據庫重啟失效,請在源庫的啟動配置文件(my.ini或my.cnf等)中添加或修改配置參數binlog_format并保存。
binlog_format=ROW
方法二:
1.為了避免源庫binlog_format格式因為數據庫重啟失效,請在源庫的啟動配置文件(my.ini或my.cnf等)中添加或修改配置參數binlog_format并保存。
binlog_format=ROW
2.確保上述配置參數binlog_format添加或修改成功后,選擇一個非業務時間段,重啟源數據庫即可。
binlog_row_image參數設置為FULL沒有立即生效
使用DRS進行MySQL遷移時,必須確保源庫的binlog_row_image參數設置為FULL,否則就會導致任務失敗。在源庫設置了binlog_row_image=FULL之后,只對新的session生效,為了關閉舊的session,需選擇一個非業務時間段,重啟源數據庫并重置任務即可。
設置binlog_row_image為FULL步驟
- 如果源數據庫為云上RDS實例,可通過RDS管理界面的參數配置,將binlog_row_image修改為FULL,完成修改后重啟源數據庫并重置任務即可。
- 如果源數據庫為本地自建庫,請參考如下步驟修復。
a. 登錄MySQL源數據庫所在服務器。
b. 手動修改my.cnf配置文件,將binlog_row_image參數值修改為FULL后保存。
binlog_row_image=full
c. 為了關閉舊的session,需選擇一個非業務時間段,重啟源數據庫并重置任務。
設置的密碼不符合目標庫的密碼復雜度要求時,如何修改密碼強度
操作場景
用戶在設置遷移用戶密碼時,設置的密碼不符合目標庫的密碼復雜度要求,需要按照用戶密碼復雜度的要求進行密碼設置。
操作步驟
以下操作適用于目標數據庫為RDS實例的情況。
步驟 1 登錄關系型數據庫服務控制臺。
步驟 2 選擇指定目標數據庫實例。
步驟 3 單擊實例名稱。
步驟 4 頁面跳轉至“基本信息”頁簽,切換至“參數修改”頁面。
步驟 5 在頁面右上角搜索框,輸入關鍵字“password”,查看搜索結果。
步驟 6 在步驟5的搜索結果中,對于表7-8列舉的參數,需要根據密碼復雜度要求進行修改,確保各參數在密碼復雜度允許的范圍內。
表 密碼參數
| 參數 | 允許值 | 說明 |
|---|---|---|
| validate_password_length | 0~2,147,483,647 | validate_password插件校驗的密碼的最小字符數。 |
| validate_password_mixed_case_count | 0~2,147,483,647 | 指定當密碼策略為MEDIUM(中)或更高時,為通過validate_password校驗,密碼至少需包含多少個大小寫字符。 |
| validate_password_number_count | 0~2,147,483,647 | 指定當密碼策略為MEDIUM(中)或更高時,為通過validate_password校驗,密碼至少需包含多少個數字。 |
| validate_password_policy | LOW, MEDIUM, STRONG | validate_password插件執行的密碼策略。 |
| validate_password_special_char_count | 0~2,147,483,647 | 指定當密碼策略為MEDIUM(中)或更高時,為通過validate_password校驗,密碼至少需包含多少個非字母數字字符。 |
步驟 7 密碼復雜度修改完成后,保存修改結果。
步驟 8 返回數據復制服務的“遷移模式”頁面,繼續執行下一步操作即可。
如何設置MongoDB數據庫分片集群的分片鍵
MongoDB數據庫中數據的分片是以集合為基本單位的,集合中的數據通過片鍵被分成多部分。
對集合進行分片時,您需要選擇一個片鍵 , 片鍵是每條記錄都必須包含的,且建立了索引的單個字段或復合字段,MongoDB數據庫按照片鍵將數據劃分到不同的數據塊中,并將數據塊均衡地分布到所有分片中。為了按照片鍵劃分數據塊,MongoDB數據庫使用基于范圍的分片方式或者基于哈希的分片方式。
表 分片鍵分類
| 分片鍵類型 | 描述 | 使用場景 |
|---|---|---|
| 基于范圍的分片鍵 | 基于范圍的分片鍵是根據分片鍵值把數據分成一個個鄰接的范圍,如果沒有指定特定的分片類型,則基于范圍的分片鍵是默認的分片類型。 特點:基于范圍的分片鍵對于范圍類型的查詢比較高效,給定一個片鍵的范圍,分發路由可以很簡單地確定哪個數據塊存儲了請求需要的數據,并將請求轉發到相應的分片中。 |
建議在分片鍵基數較大,頻率較低,并且分片鍵值不是單調變化的情況下使用基于范圍的分片鍵。 |
| 基于哈希的分片鍵 | 基于哈希的分片鍵是指MongoDB數據庫計算一個字段的哈希值,并用這個哈希值來創建數據塊。 特點:保證了集群中數據的均衡。哈希值的隨機性使數據隨機分布在每個數據塊中,因此也隨機分布在不同分片中。 |
如果分片鍵值的基數較大,擁有大量不一樣的值,或者分片鍵值是單調變化的,則建議使用基于哈希的分片鍵。 |
集合設置分片并插入文檔之后,其中的每個文檔的分片的鍵和值都是不可更改的。如果需要修改文檔的分片鍵,必須要先刪除文檔,再修改分片鍵,然后重新插入文檔。
說明
分片鍵不支持數組索引,文本索引和地理空間索引。
基于范圍的分片鍵設置
步驟 1 使用如下命令,開啟數據庫分片開關。
sh.enableSharding (database)
說明
參數database表示要開啟分片集合的數據庫。
步驟 2 設置分片鍵。
sh.shardCollection (namespace, key)
說明
- 參數namespace表示需要進行分片的目標集合的完整命名空間.。
- key表示要設置分片鍵的索引。
- 如果需要進行分片的目標集合是空集合,可以不創建索引直接進行下一步的分片設置,該操作會自動創建索引。
sh.shardCollection()
- 如果需要進行分片的目標集合是非空集合,則需要先創建索引key。然后使用如下命令設置分片鍵。
sh.shardCollection()
基于哈希的分片鍵設置
步驟 1 使用如下命令,開啟數據庫分片開關。
sh.enableSharding (database)
說明
參數database表示要開啟分片集合的數據庫。
步驟 2 設置基于哈希的分片鍵。
sh.shardCollection ( "<database>.<collection>", { <shard key> : "hashed" } , false, {numInitialChunks: 預置的chunk個數})
其中numInitialChunks值的估算方法是:db.collection.stats().size / 1010241024*1024 。
如果集合已經包含數據,則需要先使用如下命令對需要創建的基于哈希的分片鍵先創建哈希索引:
db.collection.createIndex()
然后再使用如下命令創建基于哈希的分片鍵:
sh.shardCollection()
擴大帶寬是否會對DRS正在進行中的任務產生影響
擴大云連接帶寬時需要重建帶寬鏈路,則會導致網絡斷開,此時是否會對DRS任務產生影響取決于網絡斷開的時間以及源庫IP有沒有發生變化。例如針對MySQL引擎而言,如果網絡斷開1天,而在這1天時間內源庫binlog被清理了(MySQL都有binlog清理策略,用戶側自己配置的),就無法進行任務續傳,需要重置任務。如果網絡中斷的時間很短,并且帶寬鏈路更換完成后源庫的VPN內的IP地址沒有變,則是可以繼續續傳任務,不會對DRS任務產生影響。
為什么MariaDB和 SysDB下的數據不遷移
由于某些MariaDB的版本把SysDB庫作為其系統庫(類似于MySQL官方版5.7的sys庫),所以DRS默認也將SysDB作為所有MariaDB的系統庫來處理(等同于MySQL、information_schema、performance_schema等庫)。如果SysDB確實是業務庫,您可以通過工單申請處理。
多對一的場景約束及操作建議
因業務需要,不同實例、不同表的數據需要進行合并時,數據復制服務提供的數據遷移支持多對一的場景。
操作建議
- 為避免創建任務過程中出現空間不足問題,建議提前計算源數據庫的數據量總和,根據該總和一次性規劃目標實例的磁盤空間,剩余磁盤空間需大于源庫實際數據量大小的總和(例如“源系統1”數據量大小為1GB,“源系統2”數據量大小為3GB,“源系統3”數據量大小為6GB,則目標實例的剩余磁盤空間應該大于10GB)。
- 對于MySQL引擎,目標端參數的設置需要考慮整體資源的提升,建議使用第一個任務的參數對比功能中“常規參數”的“一鍵修改”(其中max_connections除外),而“性能參數”應該結合目標端實際規格做相應的手工設置。
- 對于多對一同步任務場景,由于該場景是一個一個任務逐步創建的,后面創建任務時可能會造成已創建任務的同步阻塞,為了避免這個情況發生,請注意創建技巧。每個同步任務都會涉及創建索引步驟,而創建索引時數據庫可能會導致Schema鎖進而阻塞Schema下的其他表的數據同步,從而導致后創建的任務可能在索引創建階段對已經同步中的任務阻塞一段時間,我們可以選擇在創建同步任務最后設置為“稍后啟動”,這樣設定在業務低峰期后創建任務,從而避免后創建任務的索引創建對已有任務的同步阻塞。
- 如果涉及表級匯集的多對一同步任務,則不支持DDL,否則會導致同步全部失敗。
多對一數據遷移
數據遷移是以整體數據庫搬遷為目的,可以實現實例級多對一遷移,不支持源端具有同名的數據庫,不支持庫名映射。
圖 多對一數據遷移


操作流程
創建任務時,為方便多對一任務間的相互識別,請在創建順序上確保第一個任務進入全量遷移后再創建第二個任務。
圖操作流程


數據復制服務的操作日志在哪里查看
數據復制服務的操作日志屬于操作審計類日志,用戶可以登錄到云審計服務(Cloud Trace Service,簡稱CTS)頁面,查看當前用戶在Console頁面單擊的頁面操作,主要是涉及任務變更的管理類操作。
請單擊界面右上角的用戶名,在下拉菜單選擇“操作日志”進行查看。
已結束的任務還能重新啟動嗎
DRS已結束任務無法重新啟動。
重置任務和重新創建任務有什么區別
重置功能一般在任務暫停和失敗場景使用,DRS重置功能不會清空目標庫,客戶需要根據自己的需求選擇是否清空目標庫。任務重置后會重新進行全量同步,不需要再次配置任務。
源庫或目標庫修改密碼后如何操作
DRS任務進行過程中,可能會因為源數據庫或者目標數據庫修改密碼信息,導致連接失敗,此時需要通過數據復制服務控制臺更新為正確的信息,然后續傳任務。
操作步驟
步驟 1 在任務列表選中指定任務,單擊任務名稱。
步驟 2 進入“基本信息”頁簽,在“連接信息”模塊下,單擊“修改連接信息”。
步驟 3 在“修改連接信息”彈出框中對源庫和目標庫的密碼進行更新,更新完成后,單擊“確認”即可。
說明在上述操作未結束之前,請不要創建或者啟動遷移任務,否則會導致數據不一致。